Queues, Streams, Eventing
RabbitMQ exchanges: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the routing model stick.
Reconstruct the unit’s core mechanisms — the four exchange types, how bindings and routing keys decide delivery, the smart-broker push contract, and the failure modes — without looking back at the lesson.
- 01Why can a RabbitMQ producer never publish directly to a queue, and what does that indirection buy you?
- 02Describe the four exchange types and the routing rule each one applies.
- 03Explain the smart-broker push model and how it differs from Kafka's pull log.
- 04Why does a too-high prefetch count cause both unfairness and an outage, and what is the safe default?
- 05What is a dead-letter exchange, and which failure mode does it solve?
- 06How would you guard against an exchange silently dropping unroutable messages?
If you could reconstruct each answer from memory, you hold the unit’s spine: producers publish to an exchange, never a queue, and the type plus routing key plus bindings decide which queues get an independent copy. Direct is exact-match, fanout broadcasts, topic matches dotted * / # patterns, and headers matches attributes. The smart-broker push model acks-and-deletes, the opposite of Kafka’s replayable pull log. And the production failures are predictable: an unbound exchange drops silently without the mandatory flag, a too-high prefetch starves consumers and grows unacked memory, and a poison message with no dead-letter exchange loops forever.