Getting high availability right in RabbitMQ is one of the most consequential architectural decisions you'll make. Too few nodes and you lose quorum during a failure. Too many and you're paying for capacity you don't need. Wrong failover design and your DR configuration doesn't actually protect you when you need it.
This guide covers the fundamentals: how to size your cluster, how quorum queue HA actually works, how to design for disaster recovery across sites or availability zones, and the gotchas that catch teams off guard.
How many nodes should a RabbitMQ cluster have?
The standard recommendation for production RabbitMQ clusters is three nodes. This isn't arbitrary — it's driven by the quorum requirements of RabbitMQ's Raft consensus mechanism, which underpins quorum queues and cluster metadata management.
With three nodes: if one node goes down, you have two out of three — still a quorum majority. If two nodes go down, the remaining node will not operate as the source of truth (RabbitMQ's "pause minority" behavior correctly prevents data loss).
"The minimum sizing is three nodes in a cluster — and three is actually the recommended normal state until you get to some really high throughput concerns."
— Scott Sternloff, AceMQ Principal Architect, FIMC Discovery Call, June 2026
Why not two nodes? A two-node cluster appears to work until one node goes down — at which point neither node can determine if it's the majority or the minority, and both pause. Even-node clusters (two, four) create ambiguity; odd-node clusters (three, five, seven) do not.
Anti-affinity is mandatory: All three nodes should run on separate physical hosts (or separate availability zones if running in cloud). Running two cluster nodes on the same VM or physical host defeats HA — if that host fails, you lose majority immediately.
How does quorum queue HA actually work?
Quorum queues use Raft consensus to replicate messages across a majority of cluster nodes before acknowledging a publisher. This means:
- Messages are written to N/2+1 nodes before being acknowledged (where N is cluster size)
- In a three-node cluster, messages must be written to at least two nodes before acknowledgment
- If one node fails, messages are still available on the remaining two nodes — no data loss
- Leader election is automatic — if the primary node for a queue fails, one of the replicas is promoted
This is a substantial improvement over the old classic mirrored queue approach, which suffered from split-brain risks, inconsistent failover behavior, and required manual synchronization after node recovery.
The gotcha teams miss: Quorum protection means RabbitMQ deliberately restricts access when quorum is lost. If a network partition isolates a single node from the other two, that node pauses itself rather than potentially becoming a divergent source of truth. Design your network topology and monitoring to expect this behavior, not to work around it.
How do you size a cluster for your throughput?
Cluster sizing is driven by three factors: message rate, message payload size, and consumer capacity.
For a deployment handling approximately 1,000–2,000 messages per second with typical payload sizes in the 100–200KB range, a three-node cluster with 4–8 vCPUs per node is a reasonable baseline.
"You don't want to over-provision unnecessarily, but you also don't want to come back immediately saying we're running tight and try to get budget again. It's about what's critical with balance."
— Scott Sternloff, AceMQ Principal Architect, FIMC Discovery Call, June 2026
Memory is more often the constraint than CPU. RabbitMQ is memory-intensive when queues grow or when messages are waiting for consumers. Node memory should be sized to comfortably hold your expected queue depth at peak load, with headroom.
Disk I/O matters for quorum queues. Because quorum queues write to the WAL and segment files before acknowledging, disk throughput directly affects message acknowledgment latency. Fast SSD storage (NVMe or equivalent) is strongly recommended.
How does disaster recovery work across availability zones or sites?
Standard RabbitMQ clustering is designed for low-latency, same-datacenter operation. Stretching a cluster across availability zones or sites with meaningful latency introduces Raft consensus delay and is not recommended for geographic distances.
The correct architecture for multi-site or multi-AZ disaster recovery is warm schema replication (available in the commercial Tanzu RabbitMQ distribution).
What warm schema replication does:
- Maintains a near-real-time copy of the entire RabbitMQ schema at a secondary site: all queues, bindings, exchanges, virtual hosts, users, and permissions
- Forwards in-flight messages asynchronously to the secondary, so the secondary has the most recent synchronized state
- Allows promotion of the secondary to primary at any time with minimal recovery effort
- Supports bidirectional promotion — either site can become primary
"It's a near real-time copy of the environment. Transactions are actually sent across asynchronously and acknowledged. So instead of it being like a copy and you have to catch up to everything, it's the most recent synchronized state of the messaging broker you can get to."
— Scott Sternloff, AceMQ Principal Architect, FIMC Discovery Call, June 2026
What about DR licensing across sites?
On the commercial licensing model, environments are counted regardless of whether they're production, QA, UAT, or DR. A fully mirrored production-plus-DR configuration requires licensing for both the primary and DR cluster.
For smaller deployments, this can be optimized: your lower environments (QA, UAT) may not require DR replicas, and those environments can be sized more conservatively.
"If you're only mirroring production, then the lower environments don't need DR. Your QA environment might not need clustering at all — it's just up or down. So you can get much simpler and reduce the license count accordingly."
— Scott Sternloff, AceMQ Principal Architect, FIMC Discovery Call, June 2026
Whether you're sizing a new cluster, designing for multi-site failover, or evaluating whether warm schema replication is worth the commercial licensing cost, contact AceMQ and we'll scope it for your specific environment.