RabbitMQ is a message broker. Producers publish messages to exchanges, bindings route them to queues, and consumers receive and acknowledge deliveries. This decouples components, but it does not by itself guarantee exactly-once business processing, global ordering, or zero data loss.
Core concepts
- Exchange: applies direct, topic, fanout, or headers routing.
- Queue: stores messages according to queue type, durability, retention, and limits.
- Binding: connects an exchange to a queue or exchange with routing arguments.
- Connection/channel: network connection and multiplexed protocol session; applications should not open one connection per message.
Reliability is end to end
Publisher confirms indicate broker acceptance under configured conditions. Consumer acknowledgements indicate processing progress. Durable queues and persistent messages improve survival but still require supported queue types, replication, disk safety, backups where applicable, and tested recovery. Consumers must tolerate redelivery and duplicates.
Design from requirements
Define routing, ordering scope, throughput, message size, latency, retention, retry, dead-lettering, replay, idempotency, schema evolution, backpressure, and failure response. Monitor queue depth and age, publish/delivery/ack rates, redeliveries, consumers, unroutable/dead-lettered messages, node health, and resource alarms.
Set up a local environment, then study exchanges, queues, and replay and routing patterns.
Reviewed against current RabbitMQ documentation September 4, 2026. Original publication date preserved.