Quorum Consistency Explained

Once data lives on N replicas instead of one, a write doesn't have to reach all of them to count as successful, and a read doesn't have to check all of them either. Each only needs a quorum — a subset large enough to make a specific guarantee. The guarantee it makes, and how badly it breaks when the arithmetic is off by one, is almost entirely determined by a single inequality.

The rule: W + R > N

Say a write quorum of size W and a read quorum of size R are both drawn from the same N replicas. If W + R > N, then no matter which W replicas the write touched and which R replicas the read happens to query, the two sets are mathematically guaranteed to overlap in at least one replica — there simply aren't enough replicas left to assemble two disjoint groups of those sizes. That shared replica has the latest acknowledged write, so the read is guaranteed to see it.

Drop either quorum size by one and the guarantee disappears entirely — not partially, entirely, with no warning at read time:

W + R = N exactly isn't enough, either — the inequality is strict. At equality, a read quorum and a write quorum can still be chosen to be completely disjoint (as the second diagram shows, with room for exactly one more replica to spare), so overlap still isn't guaranteed. The Quorum Calculator checks any N/W/R combination against this rule directly, plus the fault tolerance numbers below.

What a quorum actually costs you

Every replica outside a quorum is one that was allowed to be down, slow, or partitioned away without blocking the operation. That gives three numbers, each a direct trade against consistency and latency:

• Write fault tolerance (N − W) — how many replicas can be unreachable while a write still gets enough acknowledgements.
• Read fault tolerance (N − R) — the same, for reads.
• Availability fault tolerance — the smaller of the two, since the system needs both operations to keep working.

A majority quorum — ⌊N/2⌋ + 1 for both W and R — is the smallest pair of sizes that still satisfies W + R > N for both operations at once, which is exactly why it's the default most quorum-based systems reach for: it splits fault tolerance evenly instead of maximizing one operation at the other's expense. Write-all, read-one (W=N, R=1) makes reads as fast and fault-tolerant as possible, at the cost of a write failing the moment any single replica is unreachable — and the symmetric write-one, read-all trades the other way.

Sloppy quorums: when even W and R aren't guaranteed to overlap

The W + R > N argument assumes the write quorum and read quorum are drawn from the same fixed set of N replicas every time. Dynamo-style systems quietly break that assumption under partition: if the designated replicas for a key aren't reachable, a sloppy quorum accepts the write on the next healthy nodes in the ring instead of blocking or failing outright, relying on hinted handoff to later move the data to where it belongs. That keeps writes available through a partition — but it means a read querying the "correct" R replicas can genuinely miss a write that landed on substitute nodes, even when W + R > N held on paper. It's a second, independent availability trade stacked on top of the quorum-size trade, and it's exactly why Dynamo-style systems are eventually consistent even at W=R=N.

Two different things both called "quorum"

It's easy to conflate quorums in a Dynamo-style store with quorums in a consensus system like Raft or Paxos — the word is the same, but the guarantee isn't:

• Dynamo-style replication (Cassandra, Riak, DynamoDB) uses W and R as independent, per-request knobs. Overlap just means a read can see the latest acknowledged write; nothing stops two clients from writing concurrently to disjoint quorums and producing a genuine conflict, which is the exact scenario the Vector Clock Conflict Simulator walks through.
• Consensus systems (Raft, Paxos, ZooKeeper, etcd) use a single majority quorum for everything — electing a leader and committing a log entry both require ⌊N/2⌋ + 1 votes. The same overlap argument that guarantees a Dynamo-style read sees the latest write also guarantees that two disjoint majorities can't exist at once, which is what makes it impossible for two nodes to both believe they're leader in the same term. That's a strictly stronger guarantee — linearizability, not just eventual overlap — which is the real reason CP systems like ZooKeeper and etcd pay for it in availability during a partition, while Cassandra and DynamoDB don't.

How this shows up in real systems

Cassandra exposes the quorum size directly as a per-query consistency level: ONE and ALL are the two extremes, QUORUM is the majority default, and LOCAL_QUORUM computes the majority only within the local datacenter so a cross-region link being slow doesn't add latency to every request.

DynamoDB defaults reads to eventually consistent — cheaper, and backed by just one replica — with strongly consistent reads available as an explicit, pricier opt-in that reads a quorum instead.

MongoDB's write concern "majority" paired with read concern "majority" is the same W + R > N logic by another name: a majority write plus a majority read are guaranteed to overlap, for exactly the reason the first diagram above shows.

Try it yourself

The Quorum Calculator checks any N/W/R combination against the rule above and reports write, read, and availability fault tolerance. Once you've picked a quorum size, see what still has to be decided when two writes land in the same overlapping replica at once with the Vector Clock Conflict Simulator, or what breaks when a single resource — not a replicated value — needs exclusive access with the Distributed Lock Simulator.

FAQ

If W + R > N, am I guaranteed to always get the latest write?

You're guaranteed the read quorum includes a replica holding the latest acknowledged write, and the coordinator returns whichever response has the highest version among the replicas it queried. What counts as "latest" when two writes were genuinely concurrent is a separate question — naive last-write-wins can get that part wrong under clock skew even with a correct quorum, which is exactly what the Vector Clock Conflict Simulator demonstrates.

Why does a majority quorum tolerate exactly ⌊N/2⌋ failures, not more?

Because a majority is the smallest group size for which two instances of it can't be disjoint — drop below ⌊N/2⌋ + 1 and it becomes possible to assemble two non-overlapping groups of that size, which is precisely the overlap guarantee breaking.

Is a sloppy quorum still a quorum in the W + R > N sense?

Only nominally — it satisfies the size requirement, but not the fixed-membership assumption the overlap proof relies on. That's a deliberate availability trade Dynamo-style systems make explicitly, not an accident, and it's resolved later by hinted handoff and anti-entropy rather than prevented up front.

Why do Raft and Paxos only ever use a majority, never a tunable W/R?

Because they need the overlap guarantee to hold between every pair of quorums across the system's whole lifetime — leader election now, log commits later — not just between one write and one read. A majority is the one quorum size that makes that true unconditionally; any smaller, fixed size would eventually let two non-overlapping majorities coexist.