CAP Theorem Explained: Two Scorekeepers and a Broken Walkie-Talkie

Imagine a big school football match. The field is so huge that there are two scoreboards: one at the north end and one at the south end. Each has its own scorekeeper, and they keep the scores in sync by talking over walkie-talkies.

"North here, Red team scored! It's 3–2 now." "Got it, South updated to 3–2 too!"

Then, halfway through the game, the walkie-talkie batteries die. The two scorekeepers can no longer talk. A goal is scored near the north end. A parent runs up to the south scoreboard and asks, "What's the score?"

The south scorekeeper has two choices:

1. Refuse to answer: "Sorry, I can't be sure the score is correct right now. Please wait." (Correct, but unhelpful.)
2. Answer anyway: "It's 3–2!" (Helpful, but possibly wrong, since the north side might already show 4–2.)

There is no third option where they're both always available and always correct while the walkie-talkie is broken.

That impossible choice is the CAP Theorem, and every distributed database you've met in this series (SQL vs NoSQL, replicas and shards) has to make it.

Keywords

• Distributed System: Data stored across multiple machines that talk over a network.
• Consistency (C): Every read gets the most recent write. Everyone sees the same data at the same time.
• Availability (A): Every request gets a (non-error) response, even if it might not be the newest data.
• Partition Tolerance (P): The system keeps working even when the network between machines breaks.
• Network Partition: Machines are running but can't reach each other.
• Eventual Consistency: Copies may disagree for a short time but will match once things heal.
• PACELC: An extension of CAP that also covers the trade-off when the network is healthy.

Character Mapping

• Database Nodes / Replicas: The two scorekeepers.
• Network Link: The walkie-talkie.
• Network Partition: Dead walkie-talkie batteries.
• Client Read: A parent asking for the score.
• CP Choice: "Sorry, I can't answer until we reconnect."
• AP Choice: "Here's the latest score I know!"

1. The Three Letters

C: Consistency 🎯

After a write finishes, every reader everywhere sees it. If you change your bKash PIN, no server anywhere should still accept the old one.

A: Availability 🟢

Every request to a working node gets an answer. No timeouts, no "try again later."

P: Partition Tolerance 🔌

Networks fail. Cables get cut, data centers lose connection, cloud regions hiccup. A partition-tolerant system doesn't fall apart when that happens.

2. The Real Rule: "Pick 2 of 3" Is a Bit Misleading

You'll often hear "CAP means pick any 2." But in the real world, network partitions will happen whether you like it or not. You can't opt out of P for any system spread across machines.

So the true question is:

When the network breaks, do you choose Consistency or Availability?

3. CP Systems: "Correct or Nothing" 🔒

During a partition, a CP system refuses requests it can't guarantee are correct. Some users see errors, but nobody sees wrong data.

Good for:

• Bank balances and money transfers
• Inventory for the last concert ticket (don't sell it twice!)
• Login sessions and permissions

Examples: Traditional SQL databases with synchronous replication, MongoDB (default settings), HBase, etcd, ZooKeeper.

4. AP Systems: "Always Answer" 📣

During a partition, an AP system keeps answering from whatever copy it has, even if it's slightly out of date. When the network heals, the copies sync up (eventual consistency).

Good for:

• Social media like counts and view counts
• Shopping cart contents
• Product reviews and recommendations
• DNS (Episode 1), which serves cached answers even when slightly stale

Examples: Cassandra, Amazon DynamoDB (default), CouchDB, Riak.

Fixing Conflicts After the Partition

If both sides accepted writes, they might disagree. Common fixes:

• Last Write Wins: Keep the newest timestamp. Simple, but can silently lose data.
• Merge: Combine both versions (e.g., union of two shopping carts).
• Ask the user: Like Google Docs or Git showing a conflict.

5. Real-World Walkthrough: Daraz Flash Sale ⚡

During an 11.11 flash sale, Daraz has data centers in two regions. The link between them glitches for 30 seconds.

• Product page views and likes → AP. Keep showing products and like counts. If one region shows 1,204 likes and the other shows 1,198, nobody is harmed.
• Stock count for the last 5 discounted phones → CP. Better to show "Please try again" for 30 seconds than to sell 8 phones when only 5 exist.
• Payment confirmation → CP. Never risk double-charging or losing a payment.

One app, different choices for different data. That's how real systems use CAP.

6. Bonus: PACELC, CAP's Bigger Sibling

CAP only talks about what happens during a partition. But most of the time, the network is fine. PACELC says:

If there's a Partition, choose A or C. Else (normal operation), choose Latency or Consistency.

Even on a healthy network, waiting for every replica to confirm a write makes things slower. Many systems pick lower latency and accept tiny delays in consistency, like the replication lag from Episode 11.

CP vs AP at a Glance

🍕 Explain It Like You're 5

You and your friend each have a notebook where you write down how many cookies are left in the jar. You tell each other every time someone eats one.

One day you're in different rooms and can't talk. Someone asks you, "How many cookies are left?"

You can say "I don't know for sure, let me check with my friend first" (that's Consistency). Or you can say "I think there are 5!" even though your friend might have eaten one (that's Availability).

You can't be sure and answer right away while you can't talk to each other. That's the CAP Theorem!

🎯 The System Design Interview Summary

Interviewers rarely ask "what is CAP?" directly. Instead, they watch whether you reason about it when choosing a database.

Key Takeaways for Senior Interviews:

1. P is not optional: In any distributed system, the real choice is C vs A during a partition.
2. Choose per feature, not per company: Payments can be CP while the news feed is AP.
3. Say "eventual consistency" with a time bound: "Likes may be up to a few seconds stale, which is acceptable."
4. Mention PACELC: It shows you understand the everyday latency vs consistency trade-off, not just the failure case.
5. Many databases are tunable: Cassandra and DynamoDB let you choose consistency levels per query (e.g., QUORUM reads).

Next up is the grand finale: we'll combine everything from Episodes 1–14 to design a real system from scratch: a URL Shortener.