CAP Theorem — You Can Only Pick Two (Like a Pizza Topping Rule)

What is the CAP Theorem?

Imagine you run a pizza chain with two branches — one in Mumbai and one in Delhi. Both branches share the same menu.

Now, the phone line between Mumbai and Delhi goes down (network partition). A customer in Mumbai wants to order. What do you do?

Option A: Stop taking orders until the phone line is fixed (sacrifice Availability for Consistency)

Option B: Take the order with the current menu, even if Delhi just added a new pizza you don't know about (sacrifice Consistency for Availability)

You cannot do both perfectly. That's the CAP Theorem.

The Three Properties

C — Consistency

Every read receives the most recent write. All nodes see the same data at the same time.

Analogy: Every branch of your pizza chain has the exact same menu, updated in real-time.

A — Availability

Every request receives a response (success or failure). The system is always up and responding.

Analogy: Every branch is always open and taking orders, no matter what.

P — Partition Tolerance

The system continues to operate even when network communication between nodes fails.

Analogy: Your pizza chain keeps running even when the phone line between Mumbai and Delhi is down.

Why Can't We Have All Three?

Here's the key insight: Network partitions WILL happen. Cables get cut, data centers lose connectivity, packets get dropped. In a distributed system, P is not optional — it's a fact of life.

So the real choice is between C and A when a partition occurs:

Network partition happens! 🔥

Choice 1: CP (Consistency + Partition Tolerance)
→ System stops responding until nodes sync up
→ "Sorry, we're temporarily unavailable"
→ Example: Banking systems, MongoDB (in strict mode)

Choice 2: AP (Availability + Partition Tolerance)  
→ System keeps responding but data might be stale
→ "Here's your data (might be slightly outdated)"
→ Example: Social media feeds, DNS, Cassandra

Real-World Examples

🏦 Banking System (CP)

When you transfer ₹10,000 from your account, the system MUST be consistent. You can't have your Mumbai branch showing ₹10,000 deducted while Delhi still shows the old balance.

If there's a network issue, the bank would rather show "Transaction pending" (sacrifice availability) than show wrong balances (sacrifice consistency).

📱 Instagram Likes (AP)

When you like a post, it's okay if your friend sees 999 likes while you see 1,000 for a few seconds. The system prioritizes being available (you can always like posts) over being perfectly consistent.

Eventually, all servers will sync up — this is called Eventual Consistency.

🔍 Google Search (AP)

Google has data centers worldwide. When you search, you get results from the nearest data center. Different data centers might have slightly different indexes for a few seconds after an update. But Google is ALWAYS available — that's the priority.

The Real-World Truth

In practice, most systems aren't purely CP or AP. They make nuanced trade-offs:

Strong Consistency ←————————————→ Eventual Consistency
        |                                    |
   Banking, Payments              Social Media, CDN
   Stock Trading                  Shopping Carts
   Inventory (limited stock)      User Profiles

Eventual Consistency — The Practical Middle Ground

Most modern systems use eventual consistency: data will be consistent across all nodes, but not immediately. There's a small window where different nodes might return different values.

Analogy: When you update your WhatsApp profile picture, your friend in another city might see the old picture for a few seconds. Eventually, everyone sees the new one. That delay is acceptable.

How Different Databases Handle CAP

Database	Type	Trade-off
PostgreSQL	Single node	CA (no partition to worry about)
MongoDB	CP	Consistency over availability during partitions
Cassandra	AP	Availability over consistency during partitions
DynamoDB	AP (tunable)	Can configure consistency level per query
Redis Cluster	CP	Stops writes during partition

Interview Tips

When discussing CAP in interviews:

1. Don't say "pick 2 out of 3" — say "since P is mandatory in distributed systems, the real choice is between C and A during a partition"

2. Mention PACELC — an extension of CAP: "When there's a Partition, choose A or C. Else (no partition), choose Latency or Consistency." This shows deeper understanding.

3. Give real examples — "For our payment system, we'd choose CP because showing wrong balances is unacceptable. For the notification feed, AP is fine because a 2-second delay is okay."

Key Takeaway

CAP Theorem isn't about choosing 2 out of 3 — it's about understanding that when things go wrong (and they will), you have to decide what matters more: always being correct, or always being available.

The best engineers don't just know the theorem — they know which trade-off to make for each specific use case in their system.