CAP Theorem Explained Like You Are 12: 5 Desi Examples

Key Takeaways

• CAP says in a distributed system you can only guarantee two of three at the same time: Consistency, Availability, and Partition Tolerance.
• In the real world, partition tolerance is not optional. Networks will fail. So the real engineering choice is Consistency vs Availability.
• Need correct data even if it means saying no for a while? Pick CP. Need to always answer even if the data is slightly stale? Pick AP.
• Most systems you use every day have already picked a side. Once you see the pattern, you cannot unsee it.

Wait, why should you care?

You have two servers holding the same data. Your phone hits server A, your friend’s phone hits server B. At the exact same moment, you write something.

What does your friend see?

That single question is the entire essence of the CAP theorem. Everything else is just details.

Here is the thing: distributed systems are not one computer pretending to be many. They are many computers trying very hard to look like one. And that illusion breaks the moment the network between them has a bad day.

Which, by the way, it will. Networks always have a bad day eventually.

CAP is not an abstract interview puzzle. It is the physics rule that tells you what breaks and what survives when that bad day arrives.

The three letters, without the textbook

Let us decode C, A, and P like we are sketching on a whiteboard over chai.

C is Consistency. Everyone sees the exact same data at the same time. If you update your profile photo, your friend refreshes and sees the new photo instantly. No stale copies. No “it will show up in a bit.” Same truth everywhere, right now.

A is Availability. Every request gets an answer. The system never says “sorry, try later.” It might be the freshest answer or a slightly older cached one, but it answers. It stays online.

P is Partition Tolerance. The system keeps working even when the network between its servers is broken. Server A cannot talk to server B anymore, and both still have to make a decision about what to do.

And here is the punchline: when a network partition happens, you must choose between C and A. You cannot have both.

Why? Because if server A cannot talk to server B, you have two bad options:

1. You keep answering with whatever local data you have (you chose Availability, but now your data is inconsistent).
2. You stop answering until the network is repaired (you chose Consistency, but now you are unavailable).

Want both? Sorry. Physics says no.

The blunt part: P is not a choice. If you have more than one machine, partitions will happen. Cables get cut, cloud zones go dark, switches die. Every real distributed system must tolerate partitions. The real debate is CP vs AP.

Example 1: The IPL scoreboard on shaky stadium WiFi

Picture this: Wankhede Stadium. Last over. CSK needs 6 runs off 2 balls.

There are two giant screens: one at the North stand, one at the South stand. Both pull scores from two separate servers. Right before the penultimate ball, the network cable between the two servers snaps.

Server North sees the ball: it was a SIX. Server South does not get the network packet.

A fan near the north screen shouts “WE WON!” A fan near the south screen still sees “Need 6 off 1.”

That is a partition.

If the system is CP (Consistent + Partition Tolerant): Both screens freeze immediately. They display “Score updating, please wait” until the servers can talk again and agree. The data stays 100% correct, but you stare at a loading spinner during the most dramatic ball of the tournament. You will hate it, but you will not be lied to.

If the system is AP (Available + Partition Tolerant): Both screens keep showing whatever they know. North says we won, South says we still need runs. Everyone gets an answer, but the answers disagree for a few seconds until the network heals. Availability won; consistency took a hit.

Real systems that pick AP here: DNS, IPL commentary caches, live cricket APIs. They would rather show a slightly stale score than a blank screen. Real systems that pick CP: the third umpire’s DRS system. That one must be correct, even if it takes 15 seconds.

Example 2: Hera Pheri and the flat rented to three people

You know the classic comedy scene. Babu Rao’s flat. Raju thinks he rented it, Shyam thinks he rented it, Ghanshyam thinks he rented it. Three copies of the truth, zero coordination.

That is your database without consistency.

In Hera Pheri terms:

• Consistency means there is ONE register on Babu Rao’s desk and every booking goes through it. If Raju takes the room, the register marks it, and Shyam is told “sorry, occupied.” One truth, always correct.
• Availability means Babu Rao says “haan haan, aaja” to everyone who calls, even when his phone died and he cannot verify the register. Everyone gets a yes, but three people show up with luggage at the same room.
• Partition tolerance is the phone line dying in the first place. The network between Babu Rao and his register is broken.

When the partition happens, you cannot be both consistent and available. You either stop taking bookings until the phone works (CP, consistent but unavailable), or you keep saying yes and clean up the mess later (AP, available but inconsistent).

Example 3: UPI at the chai tapri when the network blinks

You are at your regular chai tapri. You scan the QR, pay Rs 20, and hear “payment successful” on your phone. The vendor’s soundbox stays silent.

Who do you trust?

There is a network partition between your banking app, the vendor’s device, and the NPCI switch.

• CP behavior: UPI says “do not confirm until both sides reconcile.” Your money is safe, you see “pending,” and you wait 10 seconds. If it cannot confirm, it fails the transaction cleanly. Correct, but you wait in the rain.
• AP behavior: The app says success immediately based on local optimistic state and sorts out settlements later. You get your chai fast, but occasionally someone receives a refund notice ten minutes later saying “that actually failed.”

Real UPI settlement leans strictly CP. Because financial balances cannot be “eventually consistent” in the way Instagram likes can. For money, be correct first, be fast second.

Example 4: The Mumbai dabbawala system during a mega-block

The Mumbai dabbawalas are a distributed delivery network on bicycles. Harvard studied them for their legendary accuracy despite zero computer software.

On a Sunday railway mega-block, local trains stop. The Western line is disconnected from the Central line. That is a physical network partition.

Now a dabbawala on the Western line holds 50 lunchboxes heading to Nariman Point, but the Dadar sorting station is cut off.

• CP Dabbawala: Says “I will never deliver the wrong lunchbox.” If I cannot confirm the destination code, I hold the dabba. Every lunchbox delivered is 100% correct, but some people eat late.
• AP Dabbawala: Says “I must deliver something to everyone by 1 PM.” Everyone gets lunch, but two people might get someone else’s lunchbox.

In real life, dabbawalas choose CP. Their reputation is built on zero errors. They would rather be late than wrong. Your brand promise decides your CAP choice.

Example 5: The family WhatsApp group with three admins

Every family has one: 47 members, 3 admins, and good-morning forwards at 5 AM.

Your cousin adds someone to the group. At the exact same second, your aunt removes that person from another phone. Both requests hit different edge servers before syncing.

If WhatsApp were strictly CP: It would freeze both phones with a spinner until global consensus is reached.

If WhatsApp is AP (which it is): It accepts both writes locally, shows immediate success, and converges a second later. For a brief moment, half the family sees the member, half does not. Last write wins, and everyone agrees soon.

This is eventual consistency. And for a family chat, AP is the right call. A second of inconsistency in a family group is harmless; a second of inconsistency in your bank balance is catastrophic.

Summary Cheat Sheet: How to pick in real systems

Ask two practical questions:

1. If my service gives a stale answer for 5 seconds, does someone lose money, get the wrong medicine, or double-book a seat? If yes, choose CP.
2. If my service shows an error page during a network blip, will users leave and never return? If yes, choose AP.

System	Choice	Why
IRCTC Train Booking	CP	Two travelers cannot book the same seat. Correctness beats availability.
Instagram Likes & Views	AP	If like counts are off by two for a second, nobody cares. Speed matters.
Bank Account Balances	CP	Balances must reconcile accurately across all branches.
Netflix Recommendations	AP	Stale movie suggestions are vastly better than a blank error screen.
ZooKeeper / etcd	CP	Used for distributed leader election. Split-brain leads to cluster corruption.

The 30-Second Interview Answer

If an interviewer asks you to explain the CAP theorem, skip the textbook recitation. Say this:

“In any distributed system, network partitions will happen. That is P and it is unavoidable. When a partition occurs, you must choose: either keep serving requests with local data and risk staleness (AP), or refuse requests until you can guarantee global consistency (CP). Real architectures mix both per feature: payments are CP, while feeds and like counters are AP.”

Give the chai tapri UPI example. Interviewers remember clear analogies, not academic definitions.