Back to DocsRecipe

RabbitMQ Primer

A focused walkthrough on standing up RabbitMQ for reliable async messaging — exchanges, queues, bindings, and the patterns that keep your services decoupled under load.

Why a message broker

Direct HTTP calls couple services at the worst possible moment. When the downstream is slow or down, the upstream suffers. RabbitMQ sits between them, absorbing spikes with a durable queue and delivering messages when consumers are ready.

Core concepts

  • Exchange — receives messages from producers and routes them
  • Queue — stores messages until a consumer pulls them
  • Binding — a rule connecting an exchange to a queue
  • Routing key — the string the exchange inspects to decide where a message goes

Exchange types that matter

direct— one routing key, one queue. Simplest point-to-point.

topic— wildcard routing keys (order.*, #.error). Great for fan-out by event type.

fanout— ignores routing keys, copies every message to every bound queue. Broadcast.

Durability and acknowledgements

Mark exchanges and queues durable so they survive broker restarts. Publish with persistent delivery mode so messages hit disk. On the consumer side, manual ack ensures a message is only removed after processing succeeds — no silent data loss.

Putting it together

Declare the topology once at startup (exchange, queue, binding). Producers publish to the exchange with a routing key. Consumers subscribe to the queue. Add a dead-letter exchange for messages that fail repeatedly, and you have a production-grade pipeline that degrades gracefully instead of cascading failures.

Next step: Dead-letter exchanges and retry patterns — handle poison messages without losing the queue.