Queues, Streams, Eventing
RabbitMQ exchanges: multiple-choice review
Crux Multiple-choice synthesis across the exchanges unit — direct/fanout/topic/headers routing, binding keys, smart-broker push, prefetch, and dead-letter failure modes.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a topology decision you make in a real design review — not a definition to recite, but a routing tradeoff to weigh under production load.
Goal
Confirm you can connect exchange type, binding keys, the smart-broker push model, and the production failure modes — the synthesis the lesson built toward.
Quiz
Completed
You must deliver order events to three services today, expect more later, and one service only cares about EU orders. Which exchange type fits, and why?
Heads-up Fanout copies every message to every bound queue, so the EU service receives all US orders just to discard them — wasted bandwidth and a silent-data-loss risk if the in-consumer filter has a bug. Use fanout only when all consumers genuinely want everything.
Heads-up Direct is exact-match, so 'all EU order events' is not one binding; you would enumerate every concrete key and re-bind on each new event type. Fine for fixed point-to-point routing, brittle for an evolving event taxonomy.
Heads-up Headers can express it but is slower (it matches an attribute map instead of a routing key) and rarely worth it when a dotted topic key like order.created.eu carries the same intent more cheaply.
Quiz
Completed
A new consumer's queue receives nothing — no errors, no exceptions, and the producer's publish calls all return success. What is the most likely cause?
Heads-up RabbitMQ has no replayable log — routing is decided at publish time by bindings, not by a retention window. A late consumer cannot miss retained messages because there are none to retain.
Heads-up A low prefetch slows throughput but still delivers; an empty queue with zero errors points at a missing or non-matching binding, not QoS.
Heads-up RabbitMQ producers can only publish to an exchange — you cannot publish to a queue directly — so this is not an expressible failure mode.
Quiz
Completed
A topic binding uses the key order.*.eu. Which routing key matches?
Heads-up * matches exactly one word and is mandatory; order.eu has only two words, so the middle position the * requires is absent and it does not match. Use # to match zero-or-more words.
Heads-up * matches exactly one word, not several; order.*.eu requires exactly three words, so a four-word key does not match. You would need order.#.eu to catch it.
Heads-up A topic binding must match every position; the final word eu does not equal us, so the whole key fails to match regardless of the matching prefix.
Quiz
Completed
A teammate says RabbitMQ and Kafka are interchangeable queues, so a late-joining consumer can replay last week's events from either. Where is the error?
Heads-up Fanout copies live messages to currently-bound queues at publish time; it does not retain anything. A consumer added later still cannot see past events because RabbitMQ deleted each on ack.
Heads-up Prefetch governs in-flight unacked delivery, not retention or replay. Acked messages are deleted regardless of prefetch.
Heads-up Quorum queues add Raft replication for durability across node failures, not replay — an acked message is still deleted and cannot be re-read by a new consumer.
Quiz
Completed
One consumer holds a huge backlog of unacked messages while fast consumers sit idle, and broker memory keeps climbing toward the high-watermark. What is misconfigured, and what is the fix?
Heads-up Exchange type governs which queues get a copy, not how many in-flight messages one consumer holds. Starvation plus rising unacked memory is a QoS/prefetch problem, not a routing problem.
Heads-up A dead-letter exchange quarantines rejected or expired messages; it does nothing about a slow consumer hogging a large prefetch batch. The fix is lowering prefetch, not dead-lettering.
Heads-up Publisher confirms tell the producer a message was persisted; they do not control consumer-side in-flight limits. The backlog and memory growth come from a too-high prefetch.
Quiz
Completed
A consumer nacks-with-requeue on a malformed payload it can never process, and one worker is now pinned redelivering the same message forever. What is the durable fix?
Heads-up Fanout copies the same poison message to more queues — it multiplies the problem rather than removing the message from the redelivery loop. The fix is dead-lettering it out, not broadcasting it.
Heads-up A higher prefetch lets the worker hold more messages, but the poison one is still requeued and redelivered; it never drains. Only dead-lettering removes it from the loop.
Heads-up The mandatory flag returns unroutable messages to the producer at publish time; it does nothing for a message that routed correctly but fails repeatedly in the consumer. That case needs a dead-letter exchange.
Recap
The through-line is one routing decision tree: exchange type is the algorithm (direct exact-match, fanout broadcast, topic dotted-pattern with * and #, headers attribute-match), bindings plus routing keys decide which queues get an independent copy, and the smart-broker push model means an acked message is deleted — no replay, unlike Kafka. The production failures all sit one layer down: an unbound exchange drops silently unless you set mandatory or a catch-all binding, a too-high prefetch starves fast consumers and grows unacked memory, and a poison message with no dead-letter exchange loops forever. Get the exchange type and bindings right first; everything downstream depends on routing being correct.