Quorums in Distributed Systems: Why Redis and RabbitMQ Use Them So Differently

When you start working with distributed systems, one term keeps showing up again and again:

Quorum.

At first it sounds simple , just a majority of nodes agreeing on something.

But once you start looking at real systems, you realize something interesting

Different systems use quorums for completely different purposes.

Two popular systems illustrate this perfectly:

• RabbitMQ
• Redis

Both talk about quorums. Both rely on multiple nodes.

Yet the role quorum plays in each system is fundamentally different.

Let’s break that down.

First: What Exactly Is a Quorum?

A quorum simply means a majority of nodes in a cluster.

Why majority?

Because two majorities must always overlap. That overlap guarantees that a system never loses the latest committed state.

If you have three nodes:

A B C

Any quorum must contain at least two nodes. That property is the foundation of many distributed systems.

But here’s the key point:

Quorum only defines how many nodes must agree. It does not define what they are agreeing about.

And that’s where systems start to differ.

Quorums in RabbitMQ

RabbitMQ introduced Quorum Queues starting from version 3.8.

The idea behind quorum queues is simple:

A message should only be considered written if a majority of nodes have it.

Imagine a cluster with three nodes.

Node A
Node B
Node C

RabbitMQ elects a leader for each queue.

All writes go through that leader.

Message Flow

1. Producer sends message to leader
2. Leader appends message to its log
3. Leader replicates (via Raft protocol) message to followers
4. Once quorum confirms → message is committed

Example:

Producer → A : M1
A → B : replicate M1
A → C : replicate M1
B ACK
Quorum reached
Commit

As soon as two nodes confirm, the message becomes durable. This guarantees that even if one node fails, the message is not lost.

But there is a trade-off — Like always

Every write must wait for multiple nodes. Which means quorum queues are slightly slower than single-node queues. RabbitMQ accepts that trade-off in exchange for strong consistency.

Redis Uses Quorums in a Very Different Way

First Let’s look at Redis Replication

Redis replication looks completely different.Redis uses a master–replica architecture.

Master
Replica
Replica

All writes go to the master. The master then replicates data to replicas.

Client → Master
Master → Replica1
Master → Replica2

But here’s the crucial detail:

Replication is asynchronous. The master does not wait for replicas before confirming the write. This means Redis replication is eventually consistent.

Redis Cluster takes a different approach to both sharding and failover , that one deserves its own breakdown

So where does quorum appear?

Quorums in Redis Sentinel

Redis uses quorum primarily inside Redis Sentinel. Sentinel is responsible for:

• monitoring nodes
• detecting failures
• promoting new masters

Imagine three sentinel nodes monitoring Redis.

Sentinel1
Sentinel2
Sentinel3

If the master fails:

1. Sentinels detect the issue
2. A quorum must agree the master is down
3. A replica gets promoted

Example:

Sentinel1 + Sentinel2 → master is down
Quorum reached
Replica promoted to master

Notice something important.

Quorum here is not used for replication.

It is used to decide when failover should happen.

Why Redis Doesn’t Use Quorum for Replication

Redis is designed with one primary goal:

speed.

Everything is in-memory.

Introducing quorum-based writes would require:

• coordinating multiple nodes
• waiting for acknowledgements
• network round trips

That would significantly increase write latency.

Instead Redis chooses a different trade-off:

• faster writes
• asynchronous replication
• eventual consistency

For many workloads (caching, session storage, analytics) this trade-off works perfectly.

Final Thoughts

Quorums are one of those fundamental ideas in distributed systems. But understanding what the quorum protects is what really matters. RabbitMQ uses quorum to protect data consistency and ordering. Redis uses quorum to protect cluster stability during failures.

They simply optimize for different priorities.