Consider an e-commerce checkout. Placing an order needs to reserve inventory, send email, update analytics, run fraud checks, and create a shipping task. If checkout waits for every downstream system, one slow dependency turns into a slow or failed order.

RabbitMQ is a good fit when you need a real broker between producers and consumers: routing, work queues, acknowledgments, retries, dead lettering, and backpressure. It is not a replay log like Kafka and it is not a managed cloud queue like SQS. Its strength is broker-side routing and mature queue semantics.

Exchanges are the central concept. Producers publish to exchanges; exchanges route to queues through bindings; consumers read from queues. That lets you route by exact key, wildcard topic pattern, headers, or fanout without pushing routing logic into every producer.

This chapter covers the practical interview pieces: exchange types, queue semantics, producer confirms, consumer acknowledgments, durability, quorum queues, ordering limits, and when RabbitMQ is the wrong tool.

The goal is not to memorize every queue argument. It is to know which guarantees RabbitMQ gives, where those guarantees stop, and how to explain the trade-offs.