# Chapter 3 — Core Concepts (CAP, Consistency — No BS)

# Concept 3: CAP Theorem

**The most misunderstood concept in system design. Let's fix that.**

## The WhatsApp Group Analogy

Imagine a WhatsApp group with 3 people: Rahul, Priya, Deepak.

All 3 store a copy of the group messages on their phone.

Now Rahul sends a message. Network is bad. Priya gets it. Deepak doesn't.

**Now what do you do?**

**Option 1 (Choose Consistency):**

> "Nobody sees the message until ALL 3 have received it."

> ✔️ Everyone sees the same data

> ❌ Priya has to wait even though she received it

**Option 2 (Choose Availability):**

> "Priya sees the message immediately. Deepak gets it later when network recovers."

> ✔️ Everyone can keep using the app

> ❌ Deepak temporarily sees stale/old data

**You can't have both.** That's CAP.

## The 3 Letters Explained

```plaintext
C = Consistency
    Every read returns the most recent write.
    "All copies of data are identical at all times."
    
A = Availability
    Every request gets a response (even if data might be slightly old).
    "The system is always up and responding."
    
P = Partition Tolerance
    System works even if network connection between servers breaks.
    "Handle network failures gracefully."
```

> ⚠️ **In real distributed systems, P is ALWAYS required.** Networks always fail sometimes.

> So you only really choose between **C** and **A**.

| Pick C+P | Pick A+P |
| --- | --- |
| Bank transfers | Your Twitter/Instagram feed |
| Stock trades | DNS (domain name lookups) |
| Inventory: "Is item in stock?" | Shopping cart (slight staleness okay) |
| Supabase (PostgreSQL) | Cassandra, DynamoDB |

> 💡 **apt-tutor context:** User scores and leaderboard can be A+P (slightly stale is okay). But payment transactions must be C+P (exact consistency).

* * *

# 📱 Concept 4: Availability — The 9s

You'll hear engineers say "we need five nines of availability." What does that mean?

| Availability | Downtime per year | Real meaning |
| --- | --- | --- |
| 99% | 3.65 days | Unacceptable for production |
| 99.9% (3 nines) | 8.76 hours | Okay for small apps |
| 99.99% (4 nines) | 52.6 minutes | Good |
| 99.999% (5 nines) | 5.26 minutes | Used by banks, airlines |

**How do you achieve high availability?**

*   Redundancy: Run 2 copies of everything. If one dies, other takes over.
    
*   Health checks: Constantly ping servers. If dead, route traffic away.
    
*   Multi-region: Deploy in Mumbai AND Singapore. One DC burns down, other serves traffic.
    

* * *

# 🔄 Concept 5: Consistency Models

Not all consistency is the same. There's a spectrum:

## Strong Consistency

> "What you write, you immediately read."

Example: Bank balance. You transfer ₹500. Next second, both you and the receiver see the updated balance.

Cost: Slow. Need to wait for all replicas to agree.

## Eventual Consistency

> "Data will become consistent... eventually. Just not immediately."

Example: You post on Instagram. Your friend in another city might see it 2 seconds later.

Cost: Users might temporarily see stale data. But the system is fast and always available.

## Read-Your-Writes Consistency

> "After YOU write something, YOU always see your own write. Others might not see it yet."

Example: You edit your Twitter bio. You immediately see the new bio. Your followers might see the old one for a few seconds.

* * *

# 🧠 Mental Model Summary

```plaintext
Building a system? Ask yourself:

1. If two servers have different data right now, is that okay?
   YES → Eventual consistency, A+P (fast, scalable)
   NO  → Strong consistency, C+P (slower, safer)

2. What's worse: being slow or showing wrong data?
   Slow is worse → Choose Availability
   Wrong data is worse → Choose Consistency
```

* * *