Read/Write Quorum

Runs in browser

Visualize how N, R, W quorums govern consistency in distributed databases

Consistency State

STRONG
Reads always see the latest write.
W(3) + R(3) > N(5)

Parameters

Fault Tolerance

Writes survive: 2 nodes
Reads survive: 2 nodes

Replica Nodes

0/5 online

Click a node to toggle it online/offline.

Write Operation

Attempts to write to all nodes. Needs 3 acks to succeed.

Log empty

Read Operation

Reads from 3 nodes and returns the maximum version seen.

No read initiated yet.

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