Quorum and Read-Write Consistency

1The core idea#

Start with the setup. You store every piece of data on N machines (three is a common choice), and you do not have to touch all of them on every operation.

• N is how many replicas hold a copy.
• W is how many must acknowledge a write before you call it done.
• R is how many you read from before you return an answer.
• A write can block on just W of the N replicas. A read can ask one node, two, or all three, and keep the freshest answer it gets back.

The quorum is simply the count you insist on. One rule is worth tattooing on your brain:

If R + W > N, any read set and any write set must share at least one node. That shared node has the latest write, so your read can see it.

The mailbox picture makes it obvious.

• Imagine three mailboxes. Drop a copy of your letter in two of them (W = 2) and always check two of them (R = 2).
• No matter which two each of you picks, at least one mailbox is in both sets. You cannot miss the letter.
• 2 + 2 = 4, which is greater than 3, so the sets collide by force. That forced overlap is the entire trick.

Flip it and the guarantee disappears.

• W = 1, R = 1, N = 3: write to one box, read from a different box, see nothing.
• That is a legal configuration. It is blazing fast, and it is eventually consistent at best.
• Sometimes that is exactly what you want (view counts, caches). The point is to choose it on purpose.

2A concrete worked example with real numbers#

Make it physical. You are running a shopping-cart service for an online store.

• Peak traffic: 50,000 reads/second and 5,000 writes/second.
• Replication: every cart at N = 3 across three availability zones (us-east-1a, 1b, 1c).
• Timing: each replica write takes about 4 ms of disk plus network, cross-zone round trips about 2 ms one way.

The write: user adds shoes, value cart = [shoes] at version v8, running W = 2.

1. Coordinator fans the write to all three replicas at t = 0.
2. Replica in 1a persists and acks at t = 6 ms. One ack.
3. Replica in 1b persists and acks at t = 7 ms. Second ack, W = 2 satisfied.
4. Coordinator returns "write ok" at roughly t = 7 ms. User-visible write latency: about 7 ms.
5. Replica in 1c is slow this second (maybe garbage collecting). Its ack lands at t = 40 ms, long after we told the user success.

The read: user hits "view cart" 10 ms later, running R = 2.

1. Coordinator asks two replicas. Say it picks 1b (has v8) and 1c (still at v7, because its ack had not landed yet).
2. 1b returns [shoes] at v8. 1c returns [] at v7.
3. R + W = 2 + 2 = 4 > 3, so the two read replicas and the two that acked the write must overlap. Here 1b is in both sets. The coordinator sees v8 beats v7, returns [shoes], and the user sees their shoes.
4. The coordinator fires a read repair at 1c, pushing v8 so the stale replica catches up.

The capacity math matters just as much as the consistency math.

• At 5,000 writes/second with W = 2 and N = 3, each write still ships to all three replicas even though it blocks on two, so each replica absorbs 5,000 writes/second of replication traffic.
• Reads at 50,000/second with R = 2 mean 100,000 replica reads/second spread across three nodes, roughly 33,000 per node.
• Set R = 3 instead and it jumps to 150,000 replica reads/second, 50,000 per node: a 50 percent read-fanout increase for a guarantee you already had at R = 2.
• Numbers like these are what separate a hand-wave from a design.

3How it works#

A write lands at a coordinator node. The coordinator fans it to all N replicas but only blocks until W of them say "got it." The rest get the write too, they are just off the critical path. The client sees success the moment the W-th ack arrives.

Reads are the mirror image.

• The coordinator asks R replicas. Each returns a value plus a version marker, usually a logical timestamp or a vector of counters.
• The coordinator keeps the newest and hands it back.
• The part people forget: if two replicas disagree, the coordinator returns the winner and quietly pushes the fresh value to the stale one.
• That background cleanup is read repair: it is how lazy replicas catch up without a separate repair job running.

Versioning is not optional, because "newest" is not obvious in a distributed system.

• Clocks drift. Two writes close together on different coordinators can trick a plain wall-clock timestamp into picking the wrong winner and silently dropping a write.
• Serious systems lean on logical clocks or vector clocks, and sometimes hand genuine conflicts back to the application to resolve.
• More on that landmine in section 6.

N, R, and W are set per request or per table, not once for the whole cluster.

• The same database can serve a "read my latest balance" query at R = 2 and a "show me a product thumbnail" query at R = 1.
• That per-path flexibility is the point, not a footnote.

4Trade-offs#

Every quorum choice is a bet on three forces pulling against each other: consistency, latency, and availability.

• Higher W. More replicas must ack, so writes are slower and fail if too many replicas are down. Payoff: data is durable sooner across more machines.
• Higher R. You read from more replicas, so reads are slower and more fragile. Payoff: more likely to catch the latest value.
• R + W > N. Buys strong read-after-write behavior. Cost: both reads and writes now depend on more nodes being alive, which hurts availability during failures.

Here is how the common setups shake out with N = 3:

Why W = 2, R = 2 on N = 3 is the one I reach for most.

• It tolerates one node down for both reads and writes, and still guarantees overlap.
• Lose a node, keep serving. Lose two, you are degraded, but you chose that.
• Contrast the section 2 numbers: W = 2 gave a 7 ms write; W = 3 would have blocked that same write until the slow 1c replica acked at 40 ms. That is a nearly 6x latency hit on every write to defend against a failure W = 2 already covers.

Quorum consistency is not linearizability.

• Even with R + W > N, you can observe a value, then observe an older value a moment later during concurrent writes or a partial failure.
• The overlap guarantee is about a single read seeing a committed write, not about a strict global order.
• For true linearizable reads you need extra machinery: reading through a leader, a consensus protocol like Raft, or at minimum read repair plus careful version reconciliation.
• Quorums give you strong, tunable consistency, not a free lunch on ordering.

The CAP reality during a partition.

• A strict quorum system refuses requests it cannot satisfy. If three of five replicas sit on the far side of a partition, your W = 3 writes on the near side fail.
• You chose consistency over availability for that request. That is working as designed, not a bug.

5Where it is used#

This pattern shows up anywhere data is replicated without a single strong leader.

• Dynamo-style stores. Systems in the lineage of Amazon's Dynamo paper (Cassandra, Riak) expose N, R, and W directly. In Cassandra you write consistency level QUORUM or ONE or ALL per query. A session store might run ONE for speed; a payments ledger runs QUORUM or stronger. QUORUM on a keyspace with replication factor 3 means 2 replicas, which is exactly the W = 2, R = 2 example above.
• Object and blob storage. Replicated object stores use write quorums so an upload is durable across availability zones before confirming. No "200 OK" until enough zones hold the bytes. A 1a-plus-1b ack before confirming means a full zone can burn down and the object survives.
• Consensus systems, with a twist. Raft and Paxos use majority quorums too, but a majority is ceil of (N+1 over 2), so for N = 5 that is 3 nodes, and reads and writes both go through an elected leader. That leader is what gets you real linearizability.

When to reach for tunable quorums, and when to walk away.

• Reach for them when you want to keep serving during single-node failures, can live with eventual consistency on some paths, and want to dial consistency up only where it truly matters.
• Avoid them when you need strict ordering or transactions across keys. For that, go to a leadered, consensus-backed system and stop fighting physics.

6Common pitfalls and gotchas#

• Thinking R + W > N gives you linearizability. It does not. It gives you overlap. Concurrent writers can still produce stale reads and conflicts. Say this clearly in an interview and you instantly sound senior.
• Trusting wall-clock timestamps to order writes. The classic silent data loss: two writes, two coordinators, clocks off by 40 ms, last-write-wins picks the wrong one, a write vanishes with no error. Use logical or vector clocks, or accept and merge conflicts in the app. Know which one your store does.
• Forgetting sloppy quorums. To stay available during partitions, some systems let a write land on healthy but "wrong" nodes outside the normal replica set, as a temporary stand-in (a sloppy quorum with hinted handoff). It keeps you up, but during that window your R + W > N guarantee is weaker than it looks, because the reader's replica set and the writer's did not actually overlap.
• Treating the ack count as durability. If a node acked a write but crashed before durably persisting, your effective W just dropped. Durability of the ack matters, not just the count of acks.
• Setting W = N for safety. Feels safe, is brittle. One slow or dead replica and every write blocks or fails. W = 2 on N = 3 already survives a failure, and as the section 2 numbers showed, W = N would have stretched a 7 ms write to 40 ms.
• Assuming read repair is instant. It is best-effort and triggered by reads. A key nobody reads can stay stale for a long time, which is why healthy clusters also run scheduled background anti-entropy repair.

7How it shows up in interviews#

Interviewers use quorums to separate people who memorized "R + W > N" from people who actually understand replication.

Candidate: For the add-to-cart and view-cart path I will replicate carts at N = 3 across three zones and run W = 2, R = 2. A view always sees the latest committed add, I survive one zone failure, and it costs about 7 ms per write.

Interviewer: And the recently-viewed-items feed on the same page?

Candidate: I will drop that to R = 1. Stale-by-a-second is fine there, and I want the lowest read latency at 50,000 reads per second. Different path, different dial.

Interviewer: You are leaning on R + W > N. Does that give you linearizability for the checkout total?

Candidate: No, and I would not claim it does. Overlap guarantees a read sees a committed write, not a strict global order. If the checkout total needs strict ordering I will route that one write through a leader instead.

Why the strong answer lands and the weak one does not.

• The weak answer ("I'll use a quorum so it's consistent") is a single claim with nothing to probe except your backpedal.
• The strong answer names N, R, W, attaches a latency number, picks different settings for different paths, and pre-empts the linearizability trap.
• That gap is the whole evaluation.

Treat N, R, and W as per-path dials you set on purpose, and never confuse quorum overlap with a total order.

Next, try the System Design Question walkthrough on designing a replicated key-value store, where you will pick N, R, and W live under failure and defend every number.