CAP Theorem
When the network splits, every request on the wrong side gets either an error or a possibly-wrong answer. Decide which, per feature.
The story
In 2007 Amazon published the Dynamo paper, describing the storage system behind its shopping cart. The paper makes one priority very clear: adding an item to your cart must always work. A cart that says "please try again later" during a network problem costs real sales.
So Dynamo accepts writes even when replicas can't talk to each other. If a partition lets two replicas each accept a different change to your cart, Dynamo keeps both versions and merges them later. The paper is open about the cost: merging versions means an item you deleted can occasionally reappear in your cart.
Amazon decided that was acceptable. A resurrected phone charger in a cart is mildly annoying. A cart that refuses to work is lost revenue.
Now imagine the same choice for a bank balance. Two replicas, split by a partition, each allow a ₹10,000 withdrawal from an account holding ₹10,000. Merging them later doesn't give the money back. A bank makes the opposite choice: refuse the withdrawal until it can be sure.
Same theorem, opposite answers. CAP doesn't tell you which to pick. It tells you that you have to pick.
The idea
CAP names three properties of a replicated system:
- C (Consistency): every read sees the most recent write, as if there were one copy of the data. (This is linearizability, which is stronger than the C in ACID.)
- A (Availability): every request to a working node gets a non-error response.
- P (Partition tolerance): the system keeps operating when messages between nodes are lost.
The popular summary, "pick two of three", is misleading. Networks do partition. You don't get to opt out of P. So the real statement is:
When a partition happens, you choose between C and A.
There's no third branch. Node 2 can't know about a write it never received.
It's a per-feature choice, not a per-company one
One product usually contains both kinds of data:
The test question is: "What's worse for this feature, an error or a wrong answer?"
Then say what the user sees in the bad case. CP: "Payment failed, please retry." AP: "The like count is off by a few for a minute." Naming the user-visible behaviour is what makes a CAP answer sound like experience instead of a definition.
Run a partition both ways and watch what each side does:
Quorums: the dial between C and A
Many databases (Cassandra, DynamoDB-style systems) let you choose per request. With N replicas, a write waits for W acknowledgements and a read asks R replicas.
| Setting | Effect |
|---|---|
| W + R > N (e.g. 2 + 2 > 3) | Reads see the latest acknowledged write in normal operation. A minority partition can't serve requests. Leans C. |
| W = 1, R = 1 | Fast and always answers. Reads can be stale. Leans A. |
| W = N | Every write needs every replica. One dead node blocks all writes. |
(Quorums alone don't give full linearizability in every edge case, which is why systems like etcd use consensus. For an interview, W + R > N is the right first answer.)
The part CAP leaves out: PACELC
Partitions are rare. Most of the time the network is fine, and you're still trading something:
This is the trade-off you live with every day: a synchronous cross-region write adds roughly 80–150 ms to every write, while an asynchronous one is fast and can lose the last few writes in a failover. Bringing up PACELC unprompted is an easy way to show depth.
Cheat sheet
| Question | Answer |
|---|---|
| What CAP actually says | During a partition, a node either errors/waits (C) or answers possibly-stale (A) |
| "Pick 2 of 3"? | Misleading. P isn't optional, so it's C vs A during a partition. |
| "CA system"? | Only a single node, or one that assumes the network never fails |
| C in CAP vs C in ACID | CAP C = linearizable reads. ACID C = constraints hold. Different things. |
| Choosing | Per feature: "Is an error or a wrong answer worse here?" |
| CP examples | etcd, ZooKeeper, Spanner, a single-leader DB that refuses writes without its leader |
| AP examples | Cassandra / Dynamo-style stores at low quorum, DNS, CDN caches |
| The dial | W + R > N leans consistent. W = R = 1 leans available. |
| No partition? | PACELC: you're still trading latency against consistency |
| AP fallout to handle | Conflicts: last-write-wins (loses data), merges, CRDTs |
Say it in the interview
"During a partition I'd keep the payment ledger CP: if a node can't reach a quorum it rejects the write and the user sees a retry message, because a double-spend is worse than a failed payment. The like counts and feed are AP: they keep serving and reconcile afterwards. And even without partitions I'd keep ledger writes synchronous within a region, accepting the latency."
Go deeper
- SD 1 · CAP Theorem: the full chapter.
- SD 2 · Chapter 6 — Consistency vs Availability: what "consistent" really means.
- SD 3 · Q39 — CAP Theorem, Q37 — Eventual Consistency, Q38 — Strong Consistency.