Understanding RabbitMQ Classic Mirrored Queues and Quorum Queues
πππUnderstanding RabbitMQ Classic Mirrored Queues and Quorum Queuesπππ
I understood RabbitMQ only after I understood why Classic Mirrored Queues were replaced.
Classic Queues
Classic Mirrored Queues
Quorum Queues
Raft Consensus
Everyone said: "Use Quorum Queues."
But I couldn't understand why.
To understand Quorum Queues, I first had to understand how Classic Mirrored Queues worked.
ππππππππππππππππππππππππππππππππππππππππππ
RabbitMQ Queue Types
Historically, RabbitMQ supported:
Classic Queue
Classic Mirrored Queue
Quorum Queue
Stream Queue
Today, Classic Mirrored Queues are being phased out and RabbitMQ recommends Quorum Queues for replicated workloads.
Why RabbitMQ Exists
Imagine a developer opens a GitHub Pull Request.
Without RabbitMQ:
Problems:
What if the worker is unavailable?
What if all workers are busy?
What if hundreds of PRs are opened at once?
What if a worker crashes while processing a build?
Build requests could be delayed or lost.
RabbitMQ Solution
Instead of sending requests directly to workers:
RabbitMQ acts as a message broker.
Its job is to:
Receive build requests
Store them safely
Deliver them to available workers
Ensure requests are not lost
RabbitMQ Core Flow
Using CI/CD example:
Producer = GitHub Webhook
Exchange = RabbitMQ Router
Queue = Build Queue
Consumer = Build Worker
1. Classic Queue
A Classic Queue is the simplest queue type.
Messages are stored in one queue.
If the node hosting the queue fails, the queue may become unavailable.
Why Classic Mirrored Queues Were Introduced
What happens if the RabbitMQ node crashes?
Build requests may be lost.
To solve this problem, RabbitMQ introduced Classic Mirrored Queues.
2. Classic Mirrored Queue
Suppose we have five RabbitMQ nodes.
Node1
Node2
Node3
Node4
Node5
Policy: ha-mode = all
The queue is replicated across all nodes.

example: Classic Mirrored Queue
Every queue has:
One Master
Multiple Mirrors
Every queue has its own master.
Example:
builds -> Master Node3
deployments -> Master Node1
emails -> Master Node5
notifications -> Master Node2
One node can be master for many queues.
Node3 : builds, deployments, notifications
This can create hotspots.
Operational Challenges
Imagine Node3 is master for many busy queues.
Node3 handles:
Writes
Consumer delivery
ACK tracking
Replication
Mirror synchronization
Memory and CPU usage can become much higher on Node3 than other nodes.
During maintenance you need to know:
Which queues are mastered here?
Are mirrors synchronized?
Can I safely restart this node?
Mirror Synchronization Problem
Suppose Node5 is down for several hours. Meanwhile millions of build jobs are processed.
When Node5 returns:
Node5:it must synchronize again. This synchronization can be expensive and time
consuming.
ππππππππππππππππππππππππππππππππππππππππππ Enter Quorum Queues
Quorum Queues solve many of these problems using the Raft Consensus Algorithm.
Instead of: Master , Mirrors
we now have: Leader , Followers
Quorum Queue Architecture
![]() |
Quorum Queue |
Each queue has:
One Leader
Multiple Followers
Every Queue Still Has Its Own Leader
Quorum Queues do NOT have one leader for the entire cluster. Each queue has its own leader.
Example:
builds -> Leader Node3
deployments -> Leader Node5
emails -> Leader Node1
notifications -> Leader Node2
This is very similar to Classic Mirrored Queues.
What Is Different?
The biggest difference is not replication. Both systems replicate data. The biggest difference is consensus.
Raft ensures:
One leader at a time
Safe failover
Majority agreement
Faster recovery
What Is a Quorum?
A quorum means a majority of replicas.
Example:
3 replicas:
Node1 Node2 Node3
Majority: 2
Example:
5 replicas:
Node1 Node2 Node3 Node4 Node5
Majority: 3
A message is considered safe only after a majority acknowledges it.
Why Odd Numbers?
RabbitMQ commonly recommends: 3 replicas or 5 replicas....instead of: 4 replicas
With five replicas you can lose two nodes while still maintaining a majority.
Leader Election
Suppose:
Leader: Node3 Followers:
Node5 Node7Node3 crashes.
Followers automatically hold an election.
When Node3 returns:
Node3 becomes Follower and synchronizes with the new leader.
This process is automatic.
ππππππππππππππππππππππππππππππππππππππππππ
Why RabbitMQ and Amazon MQ Recommend Quorum Queues
Quorum Queues provide:
Better resiliency
Faster failure detection
Predictable failover
Safer data replication
Easier operations
Better handling of node failures
Automatic leader election
For this reason RabbitMQ and Amazon MQ recommend Quorum Queues as the preferred replicated queue type.
https://aws.amazon.com/blogs/compute/introducing-quorum-queues-on-amazon-mq-for-rabbitmq/
ππππππππππππππππππππππππππππππππππππππππππ
→ππ
Classic Mirrored Queue:
Master|MirrorsFocus: Replication
→ ππ
Quorum Queue:
Leader | FollowersFocus: Replication + Consensus + Majority Agreement
The architecture looks similar, but the way failures, recovery, synchronization, and leadership are handled is fundamentally different.
πππThe biggest lesson is:πππ
Classic Mirrored Queues replicate data.
Quorum Queues replicate data and ensure all replicas agree on that data using the Raft Consensus Algorithm.
ππππππππππππππππππππππππππππππππππππππππππ




