RabbitMQ Clustering and High Availability

RabbitMQ clustering is often misunderstood in a critical way: clustering alone does not replicate queue data. A RabbitMQ cluster shares metadata — exchanges, bindings, users — across all nodes, but queue messages live on a single node. If that node crashes, the queue's messages are inaccessible until it recovers.

Quorum queues — the only HA solution:

• To make queues genuinely highly available, use quorum queues — introduced in 3.8 and the only recommended option for new deployments
• They use Raft consensus: the leader accepts writes, replicates to followers, and acknowledges only after a majority confirms; in a 3-node cluster, 2 of 3 nodes must persist the message before the producer gets an ack
• If the leader dies, a new leader is elected in 5–10 seconds and the queue continues without data loss

Network partition handling:

• Set cluster_partition_handling to pause_minority; the minority side of a split stops accepting connections, preventing split-brain where both sides accept conflicting writes
• The default ignore lets both sides run independently, creating state divergence that requires manual cleanup — not acceptable for production

Client-side failover:

• Configure multiple broker addresses in Spring AMQP's spring.rabbitmq.addresses for round-robin reconnection, or put a load balancer in front of the cluster; Spring's CachingConnectionFactory reconnects automatically to a surviving node

The trade-off:

• Quorum queues add 1–3ms write latency per message due to the replication round-trip; for business-critical data that's a trivial cost; for high-throughput telemetry, classic queues without replication are faster and occasional message loss on node failure is acceptable

I recommend quorum queues for all business-critical queues, pause_minority for partition handling, and classic queues only for telemetry or ephemeral work where message loss on node failure is acceptable.