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.

When I first started learning RabbitMQ, I kept hearing:
  • 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:

  1. Classic Queue

  2. Classic Mirrored Queue

  3. Quorum Queue

  4. 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 Node7

Node3 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
|
Mirrors

Focus: Replication

→ πŸ’šπŸ’š

Quorum Queue:

Leader | Followers

Focus: 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.

πŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’šπŸ’š 

Popular posts from this blog

☁️ AWS Global Accelerator (GA) + Route 53

🐳 Docker Filesystem Internals (AdvancEd)

🐳 Docker Tutorial for Beginners: Step-by-Step with a Simple Example

☸️What’s Inside EKS? A Beginner’s Guide to Its Core Components

☸️ Kubernetes Taints and Tolerations(with Node Affinity)

AWS Load Balancer Controller Upgrade Guide: v2.x to v3.3

🐳 Build a Tiny Flask Web App in Docker (with Ports)

☁️ Amazon S3 Explained: More Than Just Object Storage

☸️ CoreDNS and AWS VPC CNI in EKS