Consistency & CoordinationChapter 13 · Agree to disagree
Quorums: N, W, R
Quorums: N, W, R
A quorum store keeps N copies of each item, a write counts as done once W copies confirm it, and a read asks R copies and keeps the newest answer. When W + R is more than N, every read overlaps every finished write on at least one copy, so it sees that write. Turning W and R down makes requests faster and more failure-tolerant, but lets reads miss recent writes. Even W + R > N isn't the strongest model by itself — stand-in copies, clashing writes and half-finished writes all leave gaps.
- Use when
- Leaderless stores (Cassandra, Dynamo-style) where each request chooses how many copies to wait for · Tables that need reads to see the latest write, tuned per query instead of per database · Keeping writes or reads going with some copies down
- Avoid when
- Expecting quorums alone to give linearizable reads, compare-and-set or uniqueness — that needs consensus or lightweight transactions (Consistency leg 3) · Single-leader databases with read replicas — their read-after-write story is routing (core/replication-lag)
- Trade-offs
- Higher W or R sees fresher data but waits for the slowest of those copies and fails sooner when copies are down · Sloppy quorums keep writes accepted during failures but break the overlap guarantee until hints are delivered · Read repair fixes copies as they're read; anti-entropy fixes the rest, at the cost of background work
- Requires
- CAP & PACELC
3 objectives · 5 misconceptions
- predict Predict whether a read can miss the latest confirmed write from N, W and R, and how many copies can be down before writes or reads fail.
- choose Choose W and R for a Ledger table from its read / write mix and how much staleness and downtime it tolerates — fast reads, fast writes or balanced.
- explain Explain why W + R > N still isn't linearizable — sloppy quorums, concurrent writes settled by timestamps, a failed write left on some copies — and how hinted handoff, read repair and anti-entropy bring copies back together.
- Not true: Reading and writing with W + R > N makes a store linearizable.
- Not true: A quorum means every copy has to answer.
- Not true: A write that failed to reach its quorum left no trace on any copy.
- Not true: With hinted handoff, a write saved on a stand-in node is as safe and visible as one on its real copies.
- Not true: Adding copies always makes reads faster.