Chapter 09 — The CAP Theorem

Shreyesh kolhe
July 10, 2026

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:

  • What C, A, and P actually mean
  • Why "pick 2 of 3" is a bit of a lie
  • The network partition — the moment of truth
  • CP vs AP systems (with real examples)
  • The banking vs social-media decision
  • Beyond CAP: PACELC
  • Interview Questions

1. The Three Letters

┌─────────────────────────────────────────────────────────────┐
│              CAP — three promises a system makes            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   C = CONSISTENCY                                           │
│       Every read sees the LATEST write. All nodes agree.    │
│       "You always get the true, current value."             │
│                                                             │
│   A = AVAILABILITY                                          │
│       Every request gets a (non-error) response.            │
│       "The system always answers, never says 'try later'." │
│                                                             │
│   P = PARTITION TOLERANCE                                   │
│       The system keeps working even when the network        │
│       between nodes BREAKS (messages lost/delayed).         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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 — Real Systems

CP (Consistency + Partition)AP (Availability + Partition)
During a partitionRefuses/blocks to stay correctAnswers anyway, may be stale
Good forBanking, inventory, bookingsSocial feeds, likes, DNS, carts
Motto"Better an error than a wrong answer""Better a slightly stale answer than none"
ExamplesMongoDB (default), HBase, ZooKeeper, traditional RDBMSCassandra, 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: 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

ConceptKey Takeaway
C / A / PConsistency (latest data) · Availability (always answers) · Partition tolerance (survives network breaks).
Real choiceP is mandatory → the true trade-off is C vs A, and only during a partition.
CPStay correct, may reject requests. Banking, inventory, bookings.
APStay available, may be stale. Feeds, likes, carts, DNS.
PACELCEven 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!