Read/Write Quorum
Runs in browserVisualize how N, R, W quorums govern consistency in distributed databases
Consistency State
Parameters
Fault Tolerance
Replica Nodes
0/5 onlineClick a node to toggle it online/offline.
Write Operation
Attempts to write to all nodes. Needs 3 acks to succeed.
Read Operation
Reads from 3 nodes and returns the maximum version seen.
Reference Configs (N=3)
| Config | W+R | Consistency | Notes |
|---|---|---|---|
| W=3, R=1 | 4 > 3 | Strong | Writes hit all, fast reads (Zookeeper) |
| W=2, R=2 | 4 > 3 | Strong | Balanced (Cassandra default) |
| W=1, R=3 | 4 > 3 | Strong | Read-heavy, slow writes |
| W=1, R=1 | 2 ≤ 3 | Eventual | High performance, may read stale |
| W=3, R=3 | 6 > 3 | Strong | Maximum safety, both must contact all |
About Read/Write Quorums
In distributed databases with replicated data, a quorum is the minimum number of nodes that must acknowledge an operation before it's considered successful. The relationship between N (total replicas), W (write quorum), and R (read quorum) determines the consistency guarantee of a distributed system. Understanding these trade-offs is fundamental to designing reliable, scalable data stores.
The Golden Rule: W + R > N
When W + R > N, every read quorum must overlap with every write quorum by at least one node. This overlap guarantees the reader always sees the latest write — this is strong consistency. The math is elegant: if you write to W nodes and read from R nodes, and W + R > N, then at least one node participated in both operations, so the read must see the latest write.
Example: N=5, W=3, R=3 W + R = 6 > 5 (N) → Strong Consistency ✅ Write goes to: [1, 2, 3] (3 nodes) Read comes from: [3, 4, 5] (3 nodes) Overlap: [3] (at least 1 node!) → Node 3 has the latest write, so read sees it.
Connection to the CAP Theorem
The CAP theorem states that a distributed system can only guarantee two of three properties: Consistency, Availability, and Partition tolerance. Quorum systems let you tune where you sit on this spectrum:
CP: Strong Consistency
Set W + R > N. Sacrifices availability during partitions (writes/reads may fail if not enough nodes are reachable). Systems: ZooKeeper, etcd, CockroachDB.
AP: High Availability
Set W=1, R=1. Always available but may return stale data. Requires conflict resolution (last-write-wins, vector clocks, CRDTs). Systems: Cassandra (ONE), DynamoDB.
Tunable Consistency in Practice
Modern databases let you configure consistency per query, not just per cluster. This is called tunable consistency — the killer feature of quorum-based systems.
Cassandra Consistency Levels
-- Strong consistency (W + R > N) INSERT INTO users ... USING CONSISTENCY QUORUM; SELECT * FROM users ... USING CONSISTENCY QUORUM; -- Fast writes, eventual reads INSERT INTO users ... USING CONSISTENCY ONE; SELECT * FROM users ... USING CONSISTENCY ONE; -- Maximum safety INSERT INTO users ... USING CONSISTENCY ALL; SELECT * FROM users ... USING CONSISTENCY ALL;
| Level | W/R Value | Consistency | Latency |
|---|---|---|---|
| ONE | 1 | Eventual | Fastest |
| QUORUM | ⌈(N+1)/2⌉ | Strong* | Medium |
| ALL | N | Strong | Slowest |
| LOCAL_QUORUM | ⌈(N_local+1)/2⌉ | Strong (local DC) | Low |
* Strong consistency when both reads and writes use QUORUM
Sloppy Quorums & Hinted Handoff
A strict quorum requires responses from specific designated nodes. A sloppy quorum accepts responses from any N nodes, not just the designated replicas. This dramatically improves availability during partial failures.
How Hinted Handoff Works
When a designated replica is down, a sloppy quorum writes the data to a temporary substitute node along with a "hint" about the intended recipient. When the original node recovers, the hint is forwarded and the data is restored. DynamoDB pioneered this technique. Trade-off: sloppy quorums improve availability but weaken the consistency guarantee — you might not achieve strong consistency even with W + R > N because the quorum nodes may not overlap.
Read Repair & Anti-Entropy
When a read quorum returns responses with different versions, the system performs read repair — it writes the latest version back to the stale replicas. This happens in the background and is transparent to the client.
Read Repair (Foreground)
During a read, if stale replicas are detected, immediately push the latest version to them. Cassandra does this by default on reads. Adds latency but keeps replicas in sync.
Anti-Entropy (Background)
A periodic background process compares Merkle trees between replicas to detect and fix
inconsistencies. Slower but catches issues that read repair misses (e.g., data that's
never read). Used by Cassandra's nodetool repair and DynamoDB's internal processes.
What Does W + R > N Actually Guarantee?
A common misconception is that W + R > N gives you linearizability (the strongest form of consistency). In reality, it only guarantees regular register semantics — you'll see the latest write or a concurrent write, but not necessarily in a globally ordered way. For true linearizability, you need additional mechanisms:
- Read-your-writes: No guarantee that a client immediately sees its own writes unless reads go to the same quorum
- Monotonic reads: A client might see newer data then older data on subsequent reads from different quorums
- True linearizability: Requires consensus protocols like Raft or Paxos on top of quorums (e.g., CockroachDB, etcd)
Production Systems Deep Dive
Apache Cassandra
Default: N=3, QUORUM reads/writes (W=2, R=2). Supports tunable consistency per query. Uses gossip protocol for membership, Merkle trees for anti-entropy. Sloppy quorums are opt-in (hinted handoff is enabled by default but uses strict quorums for consistency).
Amazon DynamoDB
Pioneered sloppy quorums and hinted handoff (from the 2007 Dynamo paper). Default reads are eventually consistent (fast, cheap). Strongly consistent reads cost 2x and contact all replicas. Uses vector clocks for conflict resolution.
Apache ZooKeeper / etcd
Use Raft/ZAB consensus (majority quorum for writes). All reads go through the leader for strong consistency, or followers for stale reads. N is always odd (3, 5, 7) to avoid split-brain. These are CP systems — they sacrifice availability during partitions.
CockroachDB / Spanner
Use Raft consensus per range (shard) with quorum writes. Provide serializable isolation and true linearizability. CockroachDB uses N=3 by default with majority quorum. Spanner uses synchronized clocks (TrueTime) for global ordering.
💡 System Design Interview Tips
- Default to N=3, W=2, R=2 (quorum) — strong consistency, tolerates 1 failure
- For read-heavy: N=3, W=3, R=1 — fast reads, slow writes
- For write-heavy: N=3, W=1, R=3 — fast writes, slow reads
- Always use an odd number for N to avoid split-brain
- Mention read repair and anti-entropy as consistency mechanisms
- Know the difference between strict and sloppy quorums
Further Reading
- Amazon Dynamo Paper (2007) — The paper that popularized sloppy quorums and hinted handoff.
- Cassandra Architecture: Dynamo — How Cassandra implements quorum consistency.
- Jepsen: Consistency Models — Kyle Kingsbury's definitive guide to consistency models.