Module 13 · Lesson 2 of 5
Quorums
R + W > N, and what it does and doesn't guarantee.
Gatepass moved its "seats left" counters to a leaderless store with three replicas. A fan bought two tickets, hit refresh, and the page still showed the old count. The write had succeeded. The read had succeeded. They just never talked to the same machine. Quorums are the rule that decides whether they must.
Voting on every operation
In a leaderless system there is no single node whose word is final. Instead, every operation asks a group of replicas and counts answers. Three numbers describe the setup:
- N: how many replicas hold each piece of data.
- W: how many replicas must acknowledge a write before you tell the client "done".
- R: how many replicas you ask on a read before you answer.
A write is sent to all N replicas, but it only waits for W acknowledgements. A read is sent to R replicas (or to all and waits for R replies) and returns the newest version among the answers. A replica that is down or slow simply doesn't vote. The operation succeeds as long as enough of them do.
The overlap rule
The key idea is a counting argument. If a write reached W replicas and a read asks R replicas, and R + W > N, then the two sets must share at least one replica. There is no room for them to be disjoint: N replicas can't hold W plus R different members when W + R is larger than N.
That shared replica holds the newest write, so the read sees it. The read compares versions from its R answers and picks the highest.
Play with it below. Start with N = 3, W = 2, R = 2 and try to make a read stale by clicking replicas. You can't. Then drop R to 1 and click the replica that missed the write.
Try it · quorums
Does the read see the write?
A write of v2 reached the first W replicas (orange). The read asks R replicas (violet ring). Click replicas to choose which ones the read hits.
Fresh read. Replica #2 has v2, so the read returns the newest version. With R + W = 4 > N = 3, every possible read overlaps the write on at least 1 replica. Try to make it stale: you can't.
R + W vs N
4 > 3
quorums overlap
Writes survive
1 down
replicas lost, still writable
Reads survive
1 down
replicas lost, still readable
Write waits for
2nd ack
slowest of the 2 fastest
What W and R buy you
Pick them and you pick a personality:
- N = 3, W = 2, R = 2: Balanced. Survives one node down for both reads and writes. Reads see the latest write.
- N = 3, W = 3, R = 1: Fast reads from any one replica, but a single dead node blocks all writes.
- N = 3, W = 1, R = 3: Fast writes, but reads must reach every replica, so one dead node blocks reads.
- N = 3, W = 1, R = 1: Fastest and always available, with no overlap. Reads can be stale.
- N = 5, W = 3, R = 3: Survives two nodes down and still overlaps.
Notice the trade: raising W makes writes slower and less available but makes reads cheaper, and vice versa. Latency follows the slowest of the fastest W (or R) replies. With W = 2 of 3, a single slow replica doesn't hurt you, because you stop waiting once two have answered.
For read-heavy data like show listings, people often pick a small R and a large W. For write-heavy data like click streams, the opposite.
Repairing the replicas that missed out
A write that reaches W of N replicas leaves N − W replicas behind. They catch up in two ways:
- Read repair: when a read gets different versions from its R replicas, it writes the newest value back to the stale ones.
- Anti-entropy: a background job compares replicas, often with hash trees, and copies over anything missing.
Without these, a replica that was down during a write would stay stale forever, and eventually enough stale replicas would break the overlap guarantee.
What a quorum does not guarantee
"R + W > N means strongly consistent" is the most common wrong belief about quorums. It guarantees a narrow thing: a read that starts after a write has been acknowledged will touch at least one replica holding it. Several things can still go wrong:
- Concurrent operations. A read that overlaps a write in time can see either version, and two readers can see different versions, one new and one old, in the wrong order.
- Failed writes leave debris. If a write reaches only 1 of 3 replicas and then fails to reach W, the client is told "error", yet that one replica keeps the new value. A later read may or may not return it.
- Sloppy quorums. To stay available during an outage, some stores accept writes on stand-in nodes that aren't among the N "home" replicas and hand them back later. During that window, R + W > N does not give overlap.
- Clock-based version choice. If "newest" is decided by timestamps, clock skew can make an older write win. See the clocks lesson.
- Two writers, one key. Two concurrent writes can each reach a different majority-ish set. Which one wins depends on the conflict rule, which is the topic two lessons from now.
Choosing for Gatepass
Seat inventory must never be oversold, so it stays in single-leader Postgres. The quorum store holds softer data:
- Viewers-right-now counter: N = 3, W = 1, R = 1. Stale by a second? Nobody cares, and it never blocks.
- Wishlists and saved shows: N = 3, W = 2, R = 2. A user adds a show and expects to see it on refresh.
- Notification delivery log: N = 3, W = 2, R = 1 for cheap reads, with the occasional stale check tolerated.
Check yourself
A store keeps N = 5 replicas and reads with R = 2. What is the smallest W that guarantees every read overlaps the latest acknowledged write?
Key takeaways
- A quorum system writes to W replicas and reads from R of N, and answers with the newest version it sees.
- If R + W > N, any read set and any acknowledged write set share at least one replica.
- Raising W or R improves freshness and costs latency and availability; lowering them does the reverse.
- Read repair and anti-entropy bring lagging replicas back in line.
- R + W > N is not strong consistency. Concurrency, failed writes, sloppy quorums and clock skew can all still show stale or reordered data.
Finished reading?
Mark it complete to tick it off in the course.