DBMS · Module 9 — Beyond Relational
The CAP Theorem
During a network partition a distributed system must choose consistency or availability, never both — and since partitions are unavoidable, CAP is really a choice between refusing to answer and answering with stale data.
Your database now runs on three machines. The network cable between two of them fails.
A request arrives. Do you answer with possibly-stale data, or refuse to answer at all?
There is no third option. That's the CAP theorem.
Why & what
The moment data lives on more than one machine, the machines can disagree. CAP names exactly what you must give up when they do.
CAP says a distributed system cannot have all three of: Consistency (every read gets the latest write), Availability (every request gets an answer), and Partition tolerance (it keeps working when the network splits).
How it works
Aisha's fees are stored on machines M1 and M2. The link between them breaks.
- A payment arrives at M1. M1 sets her fees to 0. It cannot tell M2 — the link is down.
- Someone reads her fees from M2. M2 still says 12,000. It has two options and no others.
- Option A — choose Consistency. M2 refuses to answer, because it can't be sure it's current. Correct, but unavailable. This is CP.
- Option B — choose Availability. M2 answers 12,000, which is stale. Available, but wrong. This is AP.
- Why P isn't optional. Networks fail — cables, switches, cloud zones. A distributed system that can't tolerate a partition is a system that breaks. So P is forced, and the real choice is only ever C or A.
Pick by the cost of being wrong. Bank balances, seat bookings, inventory → CP: refuse rather than answer wrongly. Like counts, feeds, product listings → AP: a slightly stale number is fine, an error page is not.
Pause here. Two people book the last seat on a flight during a network partition. Which side would you choose, and what happens if you choose the other?
CP — refuse the booking rather than sell one seat twice. Choose AP and both bookings succeed, and someone gets turned away at the gate.

Notice: CAP is not pick-two — P is forced, so you are only ever picking C or A.
Common confusion
"Pick any two" is the phrase everyone repeats, and it's misleading. You don't get to drop P the network will partition whether you like it or not. So CA isn't a real option for a distributed system; it only describes a single machine.
Second: CAP only applies while a partition is happening. When the network is healthy, a system can be both consistent and available. CAP describes the failure case, not everyday operation.
Third: "eventual consistency" isn't broken. It means the machines will agree once the partition heals — often within milliseconds. For a like counter that's completely fine. For a bank balance it isn't. The judgement is the answer, not the label.
Interview angle
- "Explain the CAP theorem." — Consistency, availability, partition tolerance; you can't have all three during a partition. Then the strong follow-up: P isn't optional, so the real choice is C or A.
- "Give a system that chooses each." — CP for banking, inventory, bookings. AP for social feeds, catalogues, analytics.
- "What is eventual consistency?" — Copies converge once the partition heals. Acceptable when a slightly stale read is harmless.
Recap
During a network partition a distributed system must choose consistency or availability, never both — and since partitions are unavoidable, CAP is really a choice between refusing to answer and answering with stale data.