Clustering & Quorum Queues
A cluster shares metadata, not queues
Section titled “A cluster shares metadata, not queues”A RabbitMQ cluster is several nodes that act as one logical broker. They share metadata — exchanges, bindings, users, vhosts, and which queues exist — so a client can connect to any node and see the same topology.
But here is the catch that surprises people: a classic queue lives entirely on the one node where it was declared. The other nodes know the queue exists, but they hold none of its messages. If a client connects elsewhere, its operations are simply forwarded to the node that owns the queue.
flowchart TB c["Client (connects anywhere)"] --> n1["Node 1 queue: orders (owner)"] c -.forwarded.-> n2["Node 2 (no messages)"] c -.forwarded.-> n3["Node 3 (no messages)"] n1 --> risk["Node 1 dies → queue + messages gone"]
So clustering alone gives you scale and shared topology, but not high availability for a queue’s messages. If the owning node dies, a classic (non-replicated) queue and its contents go with it.
The old answer: mirrored queues (removed in RabbitMQ 4.0)
Section titled “The old answer: mirrored queues (removed in RabbitMQ 4.0)”Historically, the fix was classic mirrored queues — replicate a queue’s contents to mirror copies on other nodes. Mirroring worked, but it was operationally painful: slow synchronization of large queues, tricky failover semantics, and edge cases that could lose or duplicate messages under partition. Classic queue mirroring was deprecated in RabbitMQ 3.x and then removed entirely in RabbitMQ 4.0 — quorum queues are its replacement, so you cannot (and should not try to) reach for mirrored queues on a current broker.
The modern answer: quorum queues
Section titled “The modern answer: quorum queues”Quorum queues are replicated queues built on the Raft consensus algorithm. A quorum queue has a leader and followers across cluster nodes; a message is only confirmed once a majority (quorum) of replicas have stored it durably.
flowchart TB p["Publisher"] --> leader["Node 1: leader replica"] leader --> f1["Node 2: follower"] leader --> f2["Node 3: follower"] leader --> conf["confirmed only after a majority store it"] leader --> ha["leader dies → a follower is elected, no messages lost"]
Because a majority must agree, quorum queues survive the loss of a minority of nodes (e.g. one node out of three) with no message loss and automatic leader election. This is the default choice for HA in modern RabbitMQ.
The trade-offs
Section titled “The trade-offs”Replication is not free, and quorum queues make deliberate choices:
| Classic queue | Quorum queue | |
|---|---|---|
| Replication | None (one node) | Raft, majority quorum |
| Node failure | Messages lost | Survives minority failure |
| Throughput | Highest | Lower (replication cost) |
| Latency | Lowest | Higher (wait for quorum) |
| Memory model | Can hold in memory | Always durable, on disk |
| Best for | Transient, high-throughput | Important messages you can’t lose |
Quorum queues are always durable and require an odd number of replicas (usually 3 or 5) to break ties. Use them for messages that matter; a classic queue can still be right for cheap, transient, high-throughput work where loss is acceptable.