Chapter 09 — The CAP Theorem
Chapter 09 — The CAP Theorem
Hey everyone! Welcome back to Namaste System Design! 🙏
This is the most name-dropped concept in all of system design — and the most misunderstood. Interviewers ask it to separate people who memorized "pick 2 of 3" from people who truly get it. Today, you become the second kind. We'll make CAP crystal clear with a two-person story.
What we will cover:
- C, A, and P explained one at a time, with a cable-cut story each
- Why "pick 2 of 3" is a bit of a lie
- The network partition — the moment of truth
- CP vs AP vs why "CA" doesn't really exist
- Real databases, sorted by category
- Beyond CAP: PACELC
- Interview Questions
1. The Three Letters
CAP describes three promises a distributed system might make. Let's take each one alone and see exactly what breaks when a network cable between two nodes gets cut.
1.1 C — Consistency
Every read sees the latest write. All nodes agree on the current value, all the time.
Node Mumbai: balance = ₹1000 Node London: balance = ₹1000 ✂️ CABLE CUT between Mumbai and London. Write hits Mumbai: balance = ₹900 A client then reads from LONDON. To stay CONSISTENT, London must NOT return its old ₹1000 (that would be wrong). It must refuse to answer until it can confirm the true latest value.
👉 Consistency means: "I'd rather say nothing than say something wrong."
1.2 A — Availability
Every request gets a real answer — never an error, never a timeout.
Same setup. Cable is STILL cut. A client reads from LONDON, which hasn't heard about the ₹900 write yet. To stay AVAILABLE, London MUST answer something. It returns its last known value: ₹1000 — even though that's now stale.
👉 Availability means: "I'd rather say something possibly-stale than say nothing."
1.3 P — Partition Tolerance
The system keeps functioning even when nodes can't talk to each other.
Cable cut between Mumbai and London. NO partition tolerance: the moment the cable drops, both nodes just... stop working entirely. The whole system halts. WITH partition tolerance: both nodes keep running and keep serving requests on their own side of the cut — they just have to decide, per request, whether to favor C or A while the cut lasts (see section 2).
👉 Partition tolerance means: "The system survives the cable being cut at all" — it doesn't say HOW it behaves, just that it doesn't fall over completely.
Note: "Consistency" here is stricter than SQL's ACID consistency — it means all nodes show the same latest data at the same time.
2. The "Pick 2 of 3" Myth
Everyone parrots "CAP says pick 2 of 3." Here's the deeper truth: in any real distributed system, network partitions WILL happen — cables fail, packets drop. So P is not optional. You must tolerate partitions.
Since P is mandatory, the REAL choice is only: When a partition happens, do you sacrifice C or A? ┌─────────────┐ ┌─────────────┐ │ CP system │ OR │ AP system │ │ keep C, │ │ keep A, │ │ drop A │ │ drop C │ └─────────────┘ └─────────────┘
So CAP is really a choice between C and A — but only during a network partition. When the network is healthy, you can have both. Say that in an interview and you instantly sound like you understand it deeply.
3. The Story That Makes It Click
Two bank clerks, Amit in Delhi and Bhavna in Mumbai, share one account ledger. Normally they sync over the phone. Your balance: ₹1000.
Suddenly, the PHONE LINE BREAKS. 📵 (a network partition)
Amit and Bhavna can no longer talk.
Now YOU walk up to Amit and say: "Withdraw ₹1000."
Amit faces an impossible choice:
───────────────────────────────
OPTION CP (choose Consistency):
"I can't reach Bhavna to confirm the balance is safe.
I REFUSE the withdrawal until the line is back."
→ Correct, but you got REJECTED (not available). 🚫
OPTION AP (choose Availability):
"Sure, here's ₹1000!" (Bhavna might ALSO give ₹1000
to someone in Mumbai → account goes to -₹1000!)
→ Always answers, but data is now INCONSISTENT. 💸
That's CAP in one image. When nodes can't talk, you either refuse to answer to stay correct (CP) or answer anyway and risk being wrong (AP). You cannot have both.
4. CP vs AP vs "CA Doesn't Exist"
4.1 CP Systems — Consistency + Partition Tolerance
During a partition, a CP system refuses or blocks requests rather than risk returning wrong data.
Bank transfer service, mid-partition:
Request: "Transfer ₹5000 from account A to B"
System: can't confirm A's true balance right now
→ REJECTS the request with an error
→ no money moves, ledger stays correct
👉 Use it when: wrong data is dangerous — banking, inventory, seat bookings.
4.2 AP Systems — Availability + Partition Tolerance
During a partition, an AP system always answers — even if the answer might be a little stale.
Social media "likes" counter, mid-partition:
Request: "How many likes on this post?"
System: this node hasn't synced the newest likes yet,
but answers anyway → "1,204 likes" (maybe 1,207
by now — nobody will notice or care)
👉 Use it when: being down is worse than being slightly stale — feeds, likes, DNS, shopping carts.
4.3 Why "CA" Doesn't Exist
A "CA" system would promise consistency AND availability, but drop partition tolerance. That means: it works fine, right up until a network partition happens — then it has no plan for handling one.
CA "system": two nodes, cable gets cut.
It never decided what to do here — because it assumed
this could never happen. In practice, it either:
- stops answering (behaved like CP anyway), or
- answers with a node that's now out of sync (behaved
like AP anyway)
In real networks, cables DO get cut. A true "CA" system
only exists if you have a SINGLE node — and a single node
isn't really a distributed system anymore.
This is why textbooks say "CA doesn't exist" for genuinely distributed systems — it's not a real third option, just an admission that partitions weren't planned for.
Visual Comparison — Real Databases by Category
| CP (Consistency + Partition) | AP (Availability + Partition) | |
|---|---|---|
| During a partition | ❌ Refuses/blocks to stay correct | ✅ Answers anyway, may be stale |
| Good for | Banking, inventory, bookings | Social feeds, likes, DNS, carts |
| Motto | "Better an error than a wrong answer" | "Better a slightly stale answer than none" |
| Examples | MongoDB (default), HBase, ZooKeeper, traditional RDBMS | Cassandra, DynamoDB, CouchDB |
DECISION RULE OF THUMB: ─────────────────────── Is wrong/stale data DANGEROUS? (money, seats, stock) → choose CP. Correctness first. Is being DOWN worse than being slightly stale? (likes, feeds, "last seen") → choose AP. Availability first.
5. Beyond CAP: PACELC (Bonus Depth)
CAP only talks about behavior during a partition. But what about normal times? PACELC extends it:
IF there's a Partition (P) → choose Availability or Consistency (A/C)
ELSE (E), normally → choose Latency or Consistency (L/C)
Translation: even with NO partition, you still trade
consistency for speed. Waiting for all nodes to agree
(strong consistency) is SLOWER than replying from one
node (low latency).
e.g. DynamoDB = PA/EL (availability + low latency)
Traditional DB = PC/EC (consistency always)
Mentioning PACELC signals you've gone one level past the textbook.
Interview Questions — Quick Fire!
Q: What is the CAP theorem?
"CAP states that a distributed system can only fully guarantee two of three properties: Consistency — every read sees the latest write; Availability — every request gets a response; and Partition tolerance — the system keeps working despite network failures between nodes. Since network partitions are unavoidable in practice, partition tolerance is mandatory, so the real trade-off is between consistency and availability during a partition."
Q: Why is 'pick 2 of 3' misleading?
"Because in any real distributed system, network partitions will happen, so you can't give up partition tolerance — P is effectively mandatory. That means the actual choice is only between consistency and availability, and only during a partition. When the network is healthy, you can have both. So CAP is better understood as: when a partition occurs, do you sacrifice C or A?"
Q: Give an example of when you'd choose CP vs AP.
"For a banking or inventory system, I'd choose CP — during a partition it's better to reject a transaction than to allow a double-withdrawal or overselling, because wrong data is dangerous. For a social media feed or a like counter, I'd choose AP — it's better to show slightly stale data than to be unavailable, since brief staleness is harmless and uptime matters more."
Q: Why doesn't 'CA' exist as a real option?
"A CA system would promise consistency and availability but not partition tolerance — meaning it has no defined behavior for when nodes can't reach each other. But in real networks, that will happen, cables fail and packets drop. When it does, a 'CA' system ends up behaving like CP or AP anyway, it just never planned for it. The only truly CA system is a single node, which isn't a distributed system at all."
Q: What does the C in CAP mean, and how is it different from ACID's C?
"In CAP, consistency means every node returns the most recent write — all nodes agree on the latest value at the same time, also called linearizability. In ACID, consistency means a transaction moves the database from one valid state to another, respecting constraints. They share a name but describe different things — CAP's C is about distributed nodes agreeing, ACID's C is about data integrity rules."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| C / A / P | Consistency (latest data) · Availability (always answers) · Partition tolerance (survives network breaks). |
| Real choice | P is mandatory → the true trade-off is C vs A, and only during a partition. |
| CP | Stay correct, may reject requests. Banking, inventory, bookings. |
| AP | Stay available, may be stale. Feeds, likes, carts, DNS. |
| "CA" | Not a real option for distributed systems — only a single node is truly CA. |
| PACELC | Even without partitions, you trade latency vs consistency. |
What's Next?
Season 2 complete — you now understand how data is stored, cached, copied, split, and the consistency trade-offs involved. In Chapter 10 we begin Season 3: Communication with message queues — how parts of a system talk asynchronously so one slow part never freezes the whole thing.
Keep designing, keep scaling! See you in the next one!
Post a Comment