Question
Single-node classic queue or three-node quorum queue cluster for low-traffic RabbitMQ
Sora Vale
0 reputation · 30 May 2022, 08:22 UTC
135.7K views
Loading…
0 reputation · 30 May 2022, 08:22 UTC
Goal: run a low-traffic RabbitMQ workload at the lowest practical infrastructure cost while retaining the ability to survive a node failure.
A single node with non-replicated classic queues avoids replication traffic and fits on one small instance, but it has no automatic failover. A minimal quorum-queue cluster needs three nodes for a write majority, which multiplies base instance, disk, and memory cost. Classic mirrored queues are deprecated in recent RabbitMQ releases, leaving quorum queues as the primary replicated option. Idle memory and disk use per quorum queue varies by release and is not a fixed published figure.
Which topology fits a cost-first constraint: one single-node classic-queue instance, or a three-node quorum-queue cluster? Is the durability benefit worth the added infrastructure for a low-throughput service? How should idle memory and disk consumption be compared before choosing?
For a cost-first constraint with low traffic: use a single node with durable classic queues unless you have a hard requirement for automatic failover within seconds of a node failure. A three-node quorum-queue cluster roughly triples base infrastructure cost (instances, disk, memory) and adds operational complexity; it only pays off when your recovery-time objective (RTO) for a node loss is near zero.
At low message rates, the dominant cost is idle per-node overhead (base memory, disk for Raft log, CPU for leader election heartbeats), not message-processing load. A three-node cluster typically costs 2.5–3× a single node in cloud instance fees alone. Unless an SLA financially penalizes minutes-to-hours of downtime during a node failure, the durability of a single node with durable messages and a reliable backup/restore process is cheaper.
Quorum queues are not a backup. Accidental deletion, logical corruption, or correlated disk failure can affect all replicas. Keep separate backups or message exports for disaster recovery regardless of topology.
What is your maximum tolerable downtime (RTO) when a single node fails?
Run a short measurement on your target RabbitMQ version instead of guessing:
rabbitmqdurable=true and persistent message settings.rabbitmqctl status or ps)lsof -p )du -sh /var/lib/rabbitmq/mnesia/...)# 1. Check RabbitMQ version and quorum queue support
rabbitmqctl version
# 2. Declare test queues (run via rabbitmqadmin or management UI)
rabbitmqadmin declare queue name=classic-test durable=true
rabbitmqadmin declare queue name=quorum-test durable=true arguments='{"x-queue-type":"quorum"}'
# 3. After 60 idle minutes, capture baselines
rabbitmqctl status | grep -A5 memory
lsof -p $(pgrep -f beam.smp) | wc -l
du -sh /var/lib/rabbitmq/mnesia/rabbit@$(hostname -s)/queues/*
# 4. Failover test (three-node cluster only)
# Stop one node, then publish/consume persistent messages to quorum-test
# Measure client reconnection pause and leader election time
# 5. Single-node recovery test
# Stop broker, restore from backup or replace node, time queue/message recovery
| Requirement | Topology | Primary Reason |
|---|---|---|
| Cost-first, RTO ≥ minutes | Single node, durable classic queues | Lowest infrastructure cost; durability via disk + backup |
| Automatic failover within seconds | Three-node quorum cluster | Raft majority survives one node loss |
| Disaster recovery (corruption, deletion) | Both need external backups | Quorum replicates state, not a backup |
Use comments to ask for clarification. Post a solution as an answer.
6,640 reputation · 30 May 2022, 12:17 UTC
RabbitMQ 3.12 introduced lazy quorum queues (disk-first mode) which dramatically lower idle memory pressure — a key factor for the cost comparison. With x-queue-mode=lazy, quorum queues keep only active Raft log entries in RAM and spill the rest to disk, cutting per-queue idle overhead from ~2–5 MB down to a few hundred KB. This makes a three-node cluster with small instances (1–2 vCPU, 2–4 GB RAM) far more viable for low-throughput HA than the default memory-first quorum behavior.
Two practical caveats: (1) lazy mode adds ~1–2 ms publish latency on cache misses, and (2) you still need synchronized clocks (<50 ms drift via chrony/ntp) and SSD-backed disks because Raft fsyncs on every write regardless of queue mode. For a true cost-first HA baseline, spin up a three-node test cluster in your target AZ topology, enable lazy quorum queues, and run rabbitmqctl list_queues name type memory disk_reads disk_writes after your expected queue count is declared — that measurement beats any published estimate.