The interviewer nods at your CP answer and asks the next question. “Five nodes, a network cut leaves three on one side and two on the other. What exactly does the two-node side do with a read?” Then: “And why did you pick W=2 and R=2?”
The core lesson, CAP theorem explained, gave the choice between consistency and availability. This companion covers the mechanics behind it: the models between strong and eventual, the quorum arithmetic, the minority side, and what PACELC says about real systems.
- CAP theorem explained: the three definitions, the worked example with three replicas and the CP/AP table.
With 3 replicas and one cut off, how many replicas make a quorum, and what does a CP system do on the cut-off side? Two make the quorum (floor(3 / 2) + 1), and the cut-off replica refuses requests that need it.
- Between linearizable and eventual there are useful middle models, such as read-your-writes. Pick the weakest one the feature can live with.
- If W + R is more than N, a read set always overlaps the latest write set. That finds the newest version but does not make the system linearizable.
- A consistent system stays correct by letting only the majority side act. The minority side times out, and an odd node count avoids a dead tie.
- PACELC classifies how a system behaves normally too. Most of the cost of consistency is paid on ordinary days, in latency.
- Dynamo and Spanner are two documented answers: stay writable and reconcile later, or coordinate on every write and stay correct.
Pick the weakest consistency model a feature needs, size R and W for a replica count, describe what the minority side of a partition does, place a real system on the PACELC grid, and contrast Dynamo with Spanner.
Which consistency model does a feature need?#
“Consistent or eventual” is a two-point scale. Real systems offer more points, and each stronger one costs more coordination.
| Model | What a reader is promised | A feature that fits |
|---|---|---|
| Linearizable | Every read sees the latest completed write, as if there were one copy | Stock decrement, lock, leader election |
| Read-your-writes | You always see your own earlier writes; others may lag | A profile edit, a just-sent message |
| Causal | If one event led to another, everyone sees them in that order | Comment threads: a reply never appears before its question |
| Eventual | If writes stop, all copies converge; a read now may be old | Like counts, search indexes |
Linearizability is the model from the Gilbert and Lynch proof: operations look as if they ran one at a time on a single node. Eventual consistency is how the Dynamo paper puts it: “all updates reach all replicas eventually”.
Choose the weakest model that keeps the feature correct. That is a judgement, but it buys the most latency and availability. A like count on eventual consistency costs nothing. A stock decrement on it costs an oversold item.
How do quorums find the latest write?#
A system with N replicas per item sets two numbers. W is how many replicas must acknowledge a write. R is how many must answer a read. The Dynamo paper states the rule: “R + W > N yields a quorum-like system”. Cassandra’s docs say the same as W + R > RF, where RF is the replication factor.
The reason is a counting fact. If W + R is more than N, the write set and the read set cannot be disjoint.
Here is the arithmetic for N = 3.
| W | R | W + R | Overlap? | Writes tolerate | Reads tolerate |
|---|---|---|---|---|---|
| 1 | 1 | 2 | no | 2 down | 2 down |
| 2 | 2 | 4 | yes | 1 down | 1 down |
| 3 | 1 | 4 | yes | 0 down | 2 down |
| 1 | 3 | 4 | yes | 2 down | 0 down |
“Tolerate” means how many replicas can be down while the operation still reaches its count: N - W for writes and N - R for reads. The common Dynamo setting is (N, R, W) = (3, 2, 2), the balanced row. Cassandra exposes the same dial per request as ONE, QUORUM (a majority, n/2 + 1) or ALL.
Latency follows the count too. Per the Dynamo paper, a get or put “is dictated by the slowest of the R (or W) replicas”, so a bigger R or W means a slower tail.
Overlap is necessary but not sufficient for linearizability. Gilbert and Lynch define consistency as every operation appearing to take effect in one global order, and quorum overlap alone does not give that. Two things break it:
- Concurrent writes. Two clients write the same item at the same time, and the replicas need a rule to pick or merge. Dynamo keeps both versions and reconciles later.
- Sloppy quorums. When replicas are down, Dynamo writes to the first N healthy nodes instead, so the overlap guarantee no longer holds. That buys write availability.
How rare are the conflicts? In the paper’s 24-hour shopping-cart profile, 99.94% of requests saw exactly one version. That is a 2007 measurement of one Amazon workload, not a promise for your system.
What does a CP system do on the minority side?#
Take a five-node consensus cluster, one that uses a majority vote to agree on a single order of writes. A majority is 3 of 5.
The majority side of three can elect a leader and keep serving. The minority side of two cannot, so it stops accepting linearizable work. Brewer’s 2000 slides name the pattern in one line: “Make minority partitions unavailable”.
etcd documents the consequence. Its FAQ says a cluster “needs a majority of nodes, a quorum, to agree on updates”. Three members tolerate 1 failure, five tolerate 2, and adding a node to an odd-sized cluster raises the number needed for quorum.
Its API guarantees say linearized requests “must go through the Raft consensus process”. What that means in practice:
- No quorum, no answer. Without a quorum these requests cannot finish. The docs do not list the exact client error, so expect timeouts and plan retries with limits (judgement).
- A tie stops everything. Four nodes split 2 and 2 leaves neither side with the 3 votes it needs. This is why consensus clusters use odd sizes.
- Failure budgets are small. Five nodes survive two failures, and a bad config push that breaks three links at once is the real risk. Spread nodes across failure zones and stage changes.
Brewer reports how this plays out at Google: no event put a Spanner quorum on the minority side of a partition, and network problems were under 8% of incidents. That is one company’s record, but it explains why a CP choice can feel like CA in practice.
How do real systems sit on the PACELC grid?#
PACELC gives each system two letters for a partition (PA or PC) and two for normal running (EL or EC). Abadi’s 2012 paper (IEEE Computer) is the usual source for sorting real systems into these four classes. The table follows the commonly reported 2012 classification, which changes with versions and settings:
| System (as classified in 2012) | PACELC | In words |
|---|---|---|
| Dynamo, Cassandra, Riak (defaults) | PA/EL | Give up consistency for availability, and for latency |
| VoltDB/H-Store, Megastore, BigTable, HBase | PC/EC | Refuse to give up consistency |
| MongoDB | PA/EC | Consistent in normal use; after a failover the old master sets unreplicated writes aside |
| PNUTS | PC/EL | Gives up consistency for latency normally; trades availability on a partition |
These labels are from 2012, so check a product’s current settings before repeating them. For DynamoDB global tables, as of 2026-10-24, the table’s mode decides. Eventual mode (MREC) replicates asynchronously, “typically within a second or less”, and resolves conflicts by last writer wins. Strong mode (MRSC) replicates synchronously to at least one other Region before a write returns, and has higher write latency. Mapping them to PA/EL and PC/EC is this lesson’s judgement, not an AWS statement.
Dynamo and Spanner: two ways to answer#
The two designs make opposite bets, and the interviewer’s follow-up is usually “when would you pick each”.
| Dynamo (2007 paper) | Spanner (2012 paper, 2017 note) | |
|---|---|---|
| Bet | Always accept writes | Always return correct data |
| Write path | Quorum of N, sloppy when nodes are down | Paxos replication plus commit wait |
| Conflicts | Keep versions, reconcile later | None visible: external consistency |
| Latency cost | Wait for the slowest of R or W | Commit wait about 5 ms, Paxos about 9 ms in the paper’s one-replica test |
| Fits | Carts, sessions, profiles | Ledgers, inventory, global SQL |
The Spanner figures come from the OSDI paper, which keeps clock uncertainty “generally less than 10ms” using GPS and atomic clocks. They are 2012 numbers on Google’s hardware, so treat them as an illustration of the cost, not a current benchmark.
Brewer sums up the relationship to CAP: Spanner is “technically a CP system”, and the clocks are not the trick. He credits Google’s private network and operations for keeping partitions rare.
Practice: size the quorum#
A store keeps N = 5 replicas of each item. Choose R and W so that reads always see the latest write, writes keep working with one replica down, and reads are as fast as possible. Then say how many replicas can be down before reads fail.
Hint
Writes tolerate N - W down, so W is at most 4. Overlap needs W + R above 5.
One reasonable answer
N = 5
W = 4 (5 - 4 = 1 down is ok)
R = 2 (4 + 2 = 6 > 5, overlap)
reads tolerate 5 - 2 = 3 down
writes tolerate 1 downW = 4 is the largest W that still tolerates one failure, and it lets R drop to 2, the smallest value that keeps W + R above N. The cost is slower writes (the slowest of four) and that three failures stop writes. For linearizable behaviour you would still need a consensus protocol, because overlap alone does not order concurrent writes.
Redo the N = 3 table from memory tomorrow without looking. If you can fill the four rows and say which failure each tolerates, the quorum question is solved.
| They ask | Answer in one line |
|---|---|
| Why W=2, R=2 with N=3? | W + R > N overlaps, and each side tolerates one failure |
| Does W + R > N give linearizability? | No: concurrent writes and sloppy quorums break it |
| Minority side of a partition? | No quorum, no leader, requests time out |
| Why odd cluster sizes? | An even split leaves no majority; an extra even node adds no tolerance |
| PACELC for a ledger? | PC/EC: pay latency for consistency every day |
| Dynamo or Spanner for a cart? | Dynamo-style: a merged cart beats an unavailable one |
| Multi-region strong writes? | Each write waits for another Region: choose Regions close together |
Check Yourself#
1.With N = 5, W = 3 and R = 3, is a read guaranteed to overlap the latest write, and how many replicas can fail for writes?
Yes: W + R = 6, more than 5. Writes tolerate N - W = 2 replicas down.
2.Why does a five-node cluster keep serving after a 3 and 2 split, but a four-node cluster does not after a 2 and 2 split?
Quorum for 5 is 3, and one side has 3. Quorum for 4 is 3, and neither side has more than 2, so both stop.
3.A team picks the strongest consistency for every feature. What does it cost?
Latency on every write and read, because more replicas must confirm, and availability on the minority side. Features such as like counts can use eventual consistency for free.
4.What would change if the cluster spanned three Regions instead of three racks?
Round trips between replicas change from within one data centre to across Regions, so quorum writes get slower and a Region-wide cut becomes a realistic minority case. Place a majority of nodes where most users are.
In One Picture#
Models: linearizable > read-your-
writes > causal > eventual
Quorum: W + R > N overlaps
Minority: no quorum, no leader
PACELC: P: A or C; Else: L or C
Dynamo: stay writable, reconcile
Spanner: coordinate, stay correctConclusion#
CAP names the choice. These mechanics let you act on it: pick the weakest model the feature needs, size the quorum from the failures you must tolerate, expect the minority side to stop, and remember that consistency costs latency on ordinary days as well.
Which follow-up would catch you out in a live round: the quorum arithmetic, the minority side, or the PACELC grid? Tell us in the comments.
- Back to the core lesson: CAP theorem explained for the definitions, the worked example and the CP/AP table.
- Where replicas come from: copying and splitting data.
- Staleness on purpose: Caching strategies.
