RabbitMQ exchanges: the routing layer that decides who gets a copy

A payments service goes live. Orders flow, but the fraud team’s queue is empty — zero messages, no errors, no exception in any log. The producer is publishing happily; the broker is accepting. Three days later someone notices: the new fraud queue was never bound to the exchange. RabbitMQ routed every message to nowhere and dropped it without a sound. The publish call returned success the whole time, because by default an exchange with no matching binding silently discards the message.

You publish to an exchange, not a queue

The first surprise for anyone arriving from a job-queue mental model: a RabbitMQ producer cannot send a message to a queue. It sends to an exchange, and the exchange decides — using its type, the message’s routing key, and the bindings that connect it to queues — which queues (if any) receive a copy. A binding is a rule that says “exchange X, deliver to queue Q when the routing key matches pattern P.” One message can land in zero queues, one queue, or many; each matched queue gets its own independent copy.

This indirection is the whole point. The producer knows nothing about consumers, queues, or how many of them exist. You can add a new consumer — that fraud queue — by creating a queue and binding it, with zero changes to the producer. That decoupling is why RabbitMQ is described as a smart broker: routing logic lives in the broker, not in the producer or consumer.

The four exchange types are four routing strategies

Every exchange has a type, and the type is the routing algorithm. There are four you will actually use:

Direct is exact-match: bind queue Q with key payments.refund, and only messages whose routing key is exactly payments.refund reach it. Fanout ignores the routing key entirely and copies every message to every bound queue — the cheapest, fastest path, ideal when N independent consumers all need the same event. Topic is the workhorse: routing keys are dot-delimited words (order.created.eu), and a binding pattern uses * to match exactly one word and # to match zero or more. So order.*.eu catches order.created.eu but not order.created.us; logs.# catches everything under logs. Headers ignores the routing key and matches on a map of header attributes, with an x-match of all or any — powerful but slower and rarely worth it; a topic key usually expresses the same intent more cheaply.

Smart broker, dumb consumer — and why that’s the opposite of Kafka

This is the senior framing that decides whether RabbitMQ even fits your problem. RabbitMQ pushes messages to consumers and deletes each one once it’s acknowledged. The broker is smart (it routes, tracks per-message acks, redelivers on failure); the consumer is relatively dumb (it processes what it’s handed and acks). A consumed-and-acked message is gone — there’s no log to rewind.

Kafka is the mirror image: a dumb broker, smart consumer pull model. Kafka is an append-only log; the broker just stores ordered records and consumers track their own offset and pull at their own pace. Nothing is deleted on consume — a message stays for the retention window, so you can replay it, add a new consumer group that reads from the beginning, or reprocess after a bug fix. RabbitMQ’s per-message ack-and-delete gives you fine-grained workflow control and complex routing; Kafka’s log gives you replay and raw throughput.

The throughput gap is large and structural. RabbitMQ classic queues reach the tens of thousands of messages/sec per queue only in a lightweight, transient config (non-durable, no publisher confirms); turn on durability, persistence, or quorum queues and that drops substantially — often to the low thousands. A single Kafka partition sustains on the order of 1 million messages/sec because it batches sequential writes to a log. The flip side: RabbitMQ delivers with sub-millisecond p50 latency (it pushes as messages arrive), while Kafka’s batching imposes a structural floor of roughly 5–15 ms p50. So the choice isn’t “which is better” — it’s complex per-message routing and low latency (RabbitMQ) versus replayable high-throughput streams (Kafka).

The failure modes that page you at 3am

Three exchange-and-queue mistakes cause most production incidents:

Unbound exchange → silent drops. This is the Hook. By default, basic.publish does not tell the producer whether the message was routed. If no binding matches, the broker drops it and the publish still returns success. The fix is the mandatory flag: set it, and an unroutable message is returned to the producer via a basic.return instead of vanishing — or route a catch-all queue with # so nothing is lost unobserved. Always alert on unroutable counts.

Prefetch (QoS) starvation and memory blowup. RabbitMQ pushes messages, and the prefetch count (basic.qos) caps how many unacknowledged messages a consumer may hold at once. Set it too high — say 1000 — and one slow consumer grabs a huge backlog while fast consumers sit idle, starving them; worse, those unacked messages stay resident in broker memory, and if processing stalls the unacked count climbs unbounded until the node hits its memory watermark and blocks all publishers. The senior default is a low prefetch (start at 1, tune up with metrics), so work spreads fairly and memory stays bounded.

Poison messages with no DLX → infinite redelivery loop. A consumer that nacks-with-requeue on a message it can never process (malformed payload, a bug it always trips) gets the same message back, forever, pinning a worker. The fix is a dead-letter exchange (DLX): configure the queue to dead-letter messages that are rejected or expire, routing them to a separate exchange and quarantine queue you can inspect and reprocess. Without a DLX, a single poison message can stall an entire pipeline.

Durability and HA: classic, mirrored, quorum

A message is only as safe as the queue holding it. Classic queues live on one node; if it dies, the queue’s messages go with it. The old answer was classic mirrored queues (replicas on other nodes), but those were deprecated and removed in RabbitMQ 4.0 — they could confirm a message before it was safely replicated, risking loss on failover. The modern answer is quorum queues: a Raft-based replicated queue that only confirms once a majority of nodes have the message. The tradeoff is concrete — replication across 3 nodes sustains roughly 30K msg/sec for 1KB messages, lower than an unreplicated classic queue, in exchange for not losing data when a node falls over. For anything you can’t afford to lose, that’s the trade a senior takes.