RabbitMQ Quorum Queues vs Classic Mirrored Queues for HA

Decide before you declare: quorum queue or mirrored queue

If you are designing a multi-node RabbitMQ cluster for high-availability message storage, the queue type you declare determines how the cluster survives node failures. Recent RabbitMQ releases recommend quorum queues and treat classic mirrored queues as deprecated. The practical takeaway: declare new HA queues as quorum queues on a three- or five-node cluster, and require publisher confirms plus consumer acknowledgments. Do not mirror classic queues for new designs unless you are maintaining an existing system that depends on them.

A quorum queue is a replicated queue that uses the Raft consensus protocol: one node acts as leader, followers replicate entries, and a majority must agree before a message is considered committed. A classic mirrored queue copies messages to every node in the mirror set and is managed by the classic queue replication layer. Majority means more than half of the configured replicas must be reachable.

Constraints to verify before choosing

• Cluster size: quorum queues need a majority. A three-node cluster survives one failure; a five-node cluster survives two. A two-node quorum queue has no majority after one node goes down.
• Message size: quorum queues are optimized for small, short-lived messages. Avoid payloads much larger than a few hundred kilobytes.
• Fan-out workloads: broadcasting the same message to many queues can increase disk and network load on quorum queue replicas.
• Durability semantics: quorum queues write every message to disk before acknowledging it. This raises latency compared with transient classic queues, so publisher confirms and manual consumer acknowledgments remain necessary.
• No conversion: you cannot change an existing classic queue into a quorum queue. You must drain or delete it and redeclare it with the x-queue-type argument set to quorum.

Version assumption: this guide assumes RabbitMQ 3.8 or later, where quorum queues are available. Confirm your installed release in the RabbitMQ release notes before relying on deprecation status for mirrored queues. Treat this as a draft for human review; verify behavior against your installed version.

Supported options compared

Factor	Quorum queue	Classic mirrored queue
Replication method	Raft consensus with elected leader	Mirroring to every node in the mirror set
Failure tolerance	Survives minority node failures; new leader elected automatically	Can continue with one mirror up, but slow consumers or split-brain can stall the mirror
Availability requirement	Majority of replicas must be reachable	At least one mirror must be up
Message size fit	Small, short-lived messages	Better suited to larger messages, though deprecated
Disk behavior	Every message written to disk before ack	Varies by queue durability and delivery mode
Conversion from classic	Not possible; delete and redeclare	N/A
Status in recent RabbitMQ	Recommended default HA queue type	Deprecated in favor of quorum queues and quorum streams

Trade-offs in practice

Quorum queues

• Automatic leader election means the cluster recovers from a leader failure without manual failover.
• Because a majority is required, a three-node cluster cannot process writes for a quorum queue after two nodes fail.
• Disk-first acknowledgment protects durability but increases publish latency. Measure this under load before adopting for latency-sensitive paths.

Classic mirrored queues

• Mirroring every message to every node can consume significant disk and network bandwidth.
• A slow consumer on one mirror can hold back the entire mirror, and network partitions can create split-brain conditions.
• Deprecation means fewer bug fixes and no new feature investment.

Declare and validate a quorum queue

Run these commands on a cluster node where you have administrative access. Replace placeholders with your cluster details.

1. Declare the queue

rabbitmqctl -n  declare_queue name= vhost= durable=true arguments='{"x-queue-type":"quorum"}'

Required permissions: a RabbitMQ user with configure and write permissions on the target vhost. If you use the HTTP management API or rabbitmqadmin, authenticate with the same user.

Expected check: the command returns without error. Risk: declaring on an existing queue name with different arguments may fail or behave unexpectedly depending on the server version; use a new queue name for testing.

2. Confirm the queue type

rabbitmqctl -n  list_quorum_queues name

Expected check: appears in the output. In the management UI, the queue’s type should display as quorum.

3. Validate leader failover (changes cluster state)

This test stops a RabbitMQ node, which interrupts service on that node. Only run it in a maintenance window or on a test cluster.

1. Identify the current leader for the queue from the management UI or rabbitmqctl output if leader information is exposed.
2. Stop the leader node: systemctl stop rabbitmq-server or rabbitmqctl -n stop_app.
3. Observe whether another quorum member becomes leader and whether reconnected producers can publish.
4. Restart the stopped node to restore the original topology: systemctl start rabbitmq-server or rabbitmqctl start_app.

Rollback: restarting the stopped node returns the cluster to its prior membership. If you deleted a classic queue to replace it with a quorum queue, messages in that queue are not recoverable unless they were consumed or backed up beforehand.

Limitations and final check

• Do not use quorum queues for broadcast-style fan-out exchanges where every consumer needs a copy of large payloads.
• Publisher confirms and manual consumer acknowledgments are still required; quorum queues protect against node failure, not against publisher crashes or consumer crashes before ack.
• Practical verification: after declaring, publish a test message, consume it with manual ack, then confirm list_quorum_queues still shows the queue and the management UI reports the expected replica count.

Decision summary

• New HA workload on three or more nodes: choose quorum queues.
• Two-node cluster: quorum queues do not provide majority-based HA after one failure; reconsider cluster size or accept the limitation.
• Existing classic mirrored queue: maintain it only if migration is not feasible; plan to replace with quorum queues on new queue names.