Overview
A quorum is the minimum number of replicas that must participate in an operation for it to count. With N replicas, a write waits for W acknowledgments and a read queries R replicas. If R + W > N, every read set overlaps every write set in at least one replica, so a read will see the latest acknowledged write.
Quorums let leaderless systems like Cassandra and DynamoDB tune consistency against latency and availability per request. Majority quorums (more than half) are also the basis of consensus algorithms like Raft and Paxos, because two majorities always overlap.
If a 5-person committee requires 3 signatures to approve a decision and 3 members to confirm the current policy, at least one person in any confirmation group signed the latest decision, so the committee can never forget it.
When to use it
- Leaderless replicated stores with tunable consistency.
- Consensus: electing leaders and committing log entries.
- Choosing consistency levels per query.
- Designing a distributed key-value store in interviews.
Where it shows up in interviews
Recognize it when: trade latency for consistency per request.
- Design a distributed key-value store
- Design a highly available cart
Recognize it when: agree on a leader or log order.
- Design a distributed lock service
- Design a configuration store
Where it is used in real software
ONE, QUORUM, LOCAL_QUORUM, and ALL let each query choose how many replicas must respond.
etcd, Consul, and ZooKeeper commit entries after a majority of nodes acknowledge them.
Writes to 4 of 6 storage copies and reads from 3 of 6 across three zones.
Key terms
- N
- Number of replicas for a key.
- W
- Replicas that must acknowledge a write.
- R
- Replicas that must answer a read.
- R + W > N
- Read and write sets overlap, so reads see the latest write.
- Sloppy quorum
- Uses substitute nodes during failures; improves availability, weakens guarantees.
How it works, step by step
- 1Pick N
Usually 3 replicas across zones.
- 2Write to all N, wait for W
Return success after W acknowledgments.
- 3Read from R replicas
Compare versions and return the newest.
- 4Read repair
Update replicas that returned stale data.
- 5Tune per workload
W=1 for fast writes, R=1 for fast reads, QUORUM for balance.
STEP 1Write x = 5 (version 2). A and B acknowledge; W = 2 is met, so the write succeeds. C is slow.
Quorum settings with N = 3
How R and W change behavior
| W | R | R + W > N? | Behavior |
|---|---|---|---|
| 1 | 1 | No | Fastest, may read stale |
| 2 | 2 | Yes | Balanced, tolerates 1 failure |
| 3 | 1 | Yes | Fast reads, writes fail if any node down |
| 1 | 3 | Yes | Fast writes, reads fail if any node down |
NOWW: 1 | R: 1 | R + W > N?: No | Behavior: Fastest, may read stale
QUORUM reads and writes (2 of 3) are the common default: consistent reads while tolerating one replica failure.
Implementation
type Versioned = { value: string; version: number }; async function quorumRead(replicas: Replica[], key: string, R: number): Promise<Versioned> { const answers: Versioned[] = []; await new Promise<void>((resolve, reject) => { let failures = 0; for (const r of replicas) { r.get(key).then((v) => { answers.push(v); if (answers.length === R) resolve(); }) .catch(() => { if (++failures > replicas.length - R) reject(new Error("quorum not reached")); }); } }); const newest = answers.reduce((a, b) => (b.version > a.version ? b : a)); // Read repair: push the newest value to replicas that answered with older versions for (const r of replicas) r.putIfNewer(key, newest).catch(() => {}); return newest;}Complexity and performance
Nodes that can be down.
Nodes that can be down.
Not the slowest.
Trade-offs
Higher R and W give stronger reads but wait for more replicas.
Sloppy quorums keep accepting writes during failures but can break the R + W > N overlap.
Variants and related techniques
Quorum within one data center for low latency in multi-region clusters.
Different quorum sizes for leader election and replication, as long as they intersect.
Common mistakes
- Assuming R + W > N gives linearizability.
Fix: Concurrent writes and sloppy quorums can still produce anomalies; use consensus for strict needs.
- Clock-based versions.
Fix: Clock skew can make an older write win; use logical versions.
Interview questions
Why does R + W > N guarantee reading the latest write?
Any set of R replicas and any set of W replicas must share at least one replica, so a read always contacts at least one replica that acknowledged the latest successful write.
What consistency level would you choose for a shopping cart?
Write with QUORUM or even ONE for availability, and read with QUORUM; merge conflicting versions. For payment, use stronger guarantees or a consensus-backed store.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Compute failure tolerance for N=5 with several R/W | Easy | Math. |
| Design tunable consistency for a key-value store | Hard | Quorums and repair. |