← Back to blogs

WTH is Quorum Reads & Writes?

If Raft gives a cluster one authoritative log, quorums give you the cheaper alternative: let writes and reads touch only a subset of replicas, and tune how often those subsets must overlap. One inequality — W + R > N — turns a replicated store from "eventually consistent" into something that guarantees a read sees the last acknowledged write.

1. Why Quorums Exist After CAP/PACELC

CAP says a partitioned system must choose between consistency and availability. PACELC says that when the network is healthy you still trade latency against consistency on every operation. Raft resolves that trade by making every write wait for a majority and every read go through the leader — that is the expensive, CP end of the spectrum.

Quorum reads and writes are the middle ground that Dynamo-style systems use: a write waits for only W of N replicas, a read contacts only R. You get to choose, per request, whether you want strong-ish reads, fast writes, or maximum availability — and the cost is some amount of consistency you must design around.

2. N, W, R, and the One Inequality

Three numbers describe a quorum configuration:

• N — the total number of replicas for a partition (replication factor).
• W — the number of replicas that must acknowledge a write before the coordinator reports success.
• R — the number of replicas a read must contact before returning an answer.

The single rule that makes everything work is:

W + R > N   →   the write set and the read set always intersect

Common configurations:

• N=3 W=2 R=2 — write needs 2 of 3, read contacts 2. Any two of three overlap. Classic quorum.
• N=5 W=3 R=3 — write survives two replica failures, read contacts three.
• W=1 R=1 — write to one, read from one. Sets can be disjoint; no guarantee.
• W=N R=1 — write to all, read from one. Strong for the last committed write, but a write is unavailable unless every replica is up.

3. What W + R > N Actually Guarantees

The guarantee is precise and easy to overstate. Assume a healthy cluster, no partitions, and a completed write:

• The write was acknowledged once W replicas stored it.
• The read contacts R replicas.
• Because W + R > N, the read's R replicas and the write's W replicas must share at least one replica.
• That shared replica holds the latest acknowledged write, so the read can return it.

What this buys you is read-your-writes for acknowledged writes: if a client gets a write acknowledged and then reads with quorum, it sees that write. That is the property most applications actually need, and it does not require a leader or a linearizable log.

4. What Quorums Do Not Guarantee

• Linearizability. Two concurrent quorum reads can still return different values if writes are racing; quorums do not impose a total order.
• Total order or causality. Quorums give you intersection, not ordering. A read may see write B without write A even if A happened before B, unless versions encode causality.
• Correctness outside the assumptions. If W or R is lowered at runtime, or replicas hold undetected stale data, or a partition splits the write set from the read set, the intersection argument silently stops holding.
• Conflict resolution. Two concurrent writes that both reach W replicas are not "resolved" by the quorum — they produce divergent versions that need a resolution policy.

5. The Write Path

A write arrives at a coordinator (any node, unlike Raft). The coordinator:

1. Generates or updates a version metadata (timestamp, vector clock, or sequence).
2. Sends the write to all N replicas (or the quorum subset).
3. Waits for acknowledgements until W replicas confirm durable storage.
4. Returns success to the client — or failure if W cannot be reached.

Replicas that did not ack will be brought up to date later by read repair or hinted handoff. The key property: W controls the durability and freshness floor, and therefore the write latency.

6. The Read Path

A read contacts R replicas, collects their values and version metadata, and picks the "most recent" according to the resolution policy (LWW or vector clock). If any replica returned a stale value, the coordinator can issue a read repair: write the fresher value back to the stale replica.

If W + R > N, at least one of the R read replicas has the latest acknowledged write — the read will return it. If W + R ≤ N, the read set can be disjoint from the write set, and the read may silently return an older value.

7. Versions and Conflict Resolution

A quorum tells you which replicas to touch, but not which value is "right." That is the job of version metadata:

• Last-writer-wins (LWW): compare wall-clock timestamps. Cheap and common (Cassandra, DynamoDB), but wrong under clock skew and silently drops the "losing" write.
• Version vectors / vector clocks: track causal context so concurrent writes are detected as siblings instead of silently overwritten. Dynamo and Riak expose these to the application for merge.
• Application-level merge: when siblings exist, the application combines them (sum of carts, longest text, union of tags) rather than picking a winner.

The resolution policy is part of the data model, not an afterthought. LWW is the default in most systems because it is simple — and it is also the most common source of silent data loss.

8. Tuning Consistency in Production

-- Cassandra: per-query consistency
SELECT * FROM orders USING CONSISTENCY QUORUM;  -- W+R > N, read-your-writes
SELECT * FROM orders USING CONSISTENCY ONE;     -- R=1, may read stale
INSERT INTO orders (id, total) VALUES (1, 299) USING CONSISTENCY QUORUM;

The same cluster can serve different guarantees per request. In practice:

• Writes that must not be lost (payments, state transitions) → W = QUORUM or W = ALL.
• Reads that must reflect acknowledged writes → R = QUORUM when W = QUORUM.
• High-throughput analytics → W=1 R=1, accepting eventual consistency.
• Strong consistency → make writes and reads both full quorum, or use a linearizable tier (DynamoDB strongly-consistent reads, Cassandra LINEARIZABLE with Paxos).

Consistency level is a per-request decision. The quadrant you live in is a default, not a prison.

9. Failure Modes and Operational Traps

• Hot replicas. If all reads use R=1, they pile onto the same replicas and the others idle.
• Slow acks. W waits for the slowest of its W replicas. One noisy neighbor inflates p99 for every quorum write.
• W=1 silently losing updates. The write is acknowledged after one replica; the rest are best-effort. That is a durability decision, not an accident.
• R=1 serving stale reads. Fine for dashboards, deadly for "has this order shipped?" flows.
• Read repair storms. After a partition heals, read repairs can amplify writes across every replica at once.
• Clock skew with LWW. If replica clocks drift, the "latest" write can be the oldest one. NTP is a prerequisite, not an option.
• Partition splits. The write quorum and read quorum can end up on opposite sides of a partition, making the intersection argument fail exactly when you need it.

10. Interactive N/W/R Quorum Calculator

Change N, W, and R and watch how the guarantee and the availability change. The table shows, for each number of simultaneous node failures, whether a write and a read can still complete.

11. Choosing W and R for a Workload

A practical decision procedure:

1. Name the invariant. "Order state must never regress after an acknowledged update" → W + R > N. "Like counts may lag 5 s" → W=1 R=1.
2. Budget the latency. Every extra ack in W adds a round trip to the slowest member of that quorum.
3. Pick a default, tune per request. A payment write uses quorum; a recommendations read uses one replica.
4. Design the conflict policy now. LWW is a bet on your clocks. If concurrent same-key writes are possible and loss is unacceptable, use version vectors or CRDTs.
5. Test the partition drill. Split the cluster and verify which side serves stale reads and which fails writes — then document it.

12. Key Takeaways

• W + R > N guarantees the read set intersects the write set: a quorum read sees the last acknowledged write.
• Quorums are a per-request consistency knob, not a property of the database binary.
• They do not provide linearizability, ordering, or conflict resolution — version metadata does.
• W and R trade availability against consistency; the calculator makes that trade visible.
• Operationally, watch hot replicas, slow acks, clock skew with LWW, and read-repair storms.

Quorums tell you which replicas to contact. They do not tell you whether two updates were concurrent — that is the job of vector clocks and conflict resolution, where the exact moment a divergence becomes a conflict is defined precisely.