The RabbitMQ Clustering and Sizing Guide

Quorum queues need a majority, so the node count is odd: three survives one failure, five survives two. Nodes go on separate physical hosts, in separate availability zones where the cloud offers them, on a network with low and stable latency between them. Two-node clusters cannot form a majority and are worse than one node; even counts waste a node. Do not stretch a cluster across regions.

Quorum queues for anything that must survive a node loss; they replicate with Raft, elect leaders on failure, and support delivery limits and dead-lettering. Streams for high-throughput fan-out and replay. Classic queues for transient, non-replicated traffic only. Classic mirrored queues are deprecated and should be migrated, not tuned.

Memory is set by backlog: a queue that normally holds nothing can hold millions of messages during a consumer outage, and that is the case the node must survive. Disk is set by the same backlog plus quorum-queue segments and the write-ahead log. CPU is set by Erlang scheduler headroom under peak publish and consume rates, with dedicated cores on virtualised hosts. Set vm_memory_high_watermark and disk_free_limit to the real host so alarms fire before the node does, and alert on the alarm.

cluster_partition_handling is pause_minority in production: the minority side pauses, the majority keeps serving, and there is nothing to reconcile on heal. autoheal lets both sides accept writes and then discards one side, which is data loss by design. ignore is for a lab. Combine with quorum queues and an odd node count and most partition incidents become a paused node and a page rather than a data-loss investigation.

Defaults assume a LAN. On cloud and WAN links set heartbeats longer, tune tcp_listen_options for keepalive and buffers, and raise the Erlang net_ticktime so transient latency does not register as a node failure. Keep clocks on NTP. Validate under real conditions; a cluster that passes in a lab and partitions weekly in production usually has a net_ticktime problem.

Queue type, delivery limits, dead-letter exchanges, TTL, max-length and overflow behaviour belong in policies matched by pattern, so a topology change does not require a client redeploy and an auditor can read the intent in one place. Targeted policies, not blanket ones; a policy that matches every queue is how mirroring got out of hand in the first place. Keep the policies in version control alongside the definitions export.

Long-lived connections with pooled channels, bounded prefetch, prompt acknowledgements, publisher confirms for anything that must not be lost, and automatic connection recovery. Most cluster symptoms — climbing unacked counts, file-descriptor exhaustion, memory that looks like a leak — start in client code. Review the clients as part of the cluster design, not after the first incident.