# CAP Theorem — What Actually Happens When Distributed Systems Can't Talk to Each Other?

  
When I first heard about the CAP Theorem, it sounded like one of those things that you just have to memorize.

**C = Consistency** **A = Availability** **P = Partition Tolerance**

And then the famous line:

> "You can only have two out of three."

Okay... but why?

What is actually happening inside the system?

Once I started looking at it as a real problem rather than a definition to memorize, CAP became much easier to understand

So let's forget the textbook definition for a moment and imagine a situation

* * *

## Imagine We Have Two Servers

Suppose our application has two servers.

```text
             Users
               |
        ┌──────┴──────┐
        ↓             ↓
     Server A      Server B
```

Both servers have the same information.

For example, let's say they know that:

```text
Account balance = ₹100
```

Everything is working fine.

Server A can talk to Server B, and Server B can talk to Server A.

Now imagine something goes wrong with the network.

Not the servers.

**The network between them.**

```text
     Server A     X     Server B
       ₹100              ₹100
```

Both servers are still running.

But they can't communicate.

This is called a **network partition**.

And this is where CAP gets interesting.

* * *

## Okay, But What Exactly Is a Partition?

Think about two people talking on two different phones.

Person A says:

> "I just updated the information."

Person B should normally hear that.

But suddenly the call drops.

Both people are still there.

Both phones are working.

They just can't talk to each other.

That's basically what a network partition looks like in a distributed system.

One part of the system is alive.

The other part is alive.

But they can't communicate.

And this is the **P — Partition Tolerance** part of CAP.

A distributed system has to be prepared for this kind of failure because networks aren't perfect.

* * *

# Now Things Get Interesting

Let's go back to our two servers.

Initially:

```text
Server A → ₹100
Server B → ₹100
```

Now the network breaks.

Then a user connected to Server A withdraws ₹50.

Server A now knows:

```text
₹50
```

But Server B still thinks:

```text
₹100
```

Remember, Server A can't tell Server B about the update because the network is broken.

Now another user asks Server B:

> "What's the balance?"

And here comes the actual CAP problem.

Server B has two choices.

* * *

# Choice 1: "I'm Not Going to Lie to You."

Server B knows that it might not have the latest information.

So it could say:

> "I can't give you a reliable answer right now."

The user doesn't get a response.

That's bad for **availability**.

But we're protecting **consistency**.

We don't want to tell the user:

> "Your balance is ₹100"

when we know that the actual latest balance could be ₹50.

So we're basically saying:

**I'd rather not answer than give you potentially wrong information.**

That's the idea behind a **CP** approach.

```text
Consistency ✅
Availability ❌
Partition Tolerance ✅
```

* * *

# Choice 2: "I'll Just Give You What I Know."

Now imagine Server B says:

> "Your balance is ₹100."

The user gets an answer.

Great.

The system is available.

But there's a problem.

The answer is outdated.

The actual latest value is ₹50.

So now we've chosen:

```text
Availability ✅
Consistency ❌
Partition Tolerance ✅
```

That's the basic idea behind an **AP** approach.

And this is basically the CAP trade-off.

* * *

# So What Is Consistency Actually Saying?

This is where I think people often make CAP more complicated than it needs to be.

In the CAP context, consistency basically means:

> If a write has successfully happened, subsequent reads should see that latest value.

Imagine you change your status from:

```text
Offline
```

to:

```text
Online
```

If I immediately check your status and get:

```text
Offline
```

from another part of the system, something isn't consistent.

The system hasn't caught up with the latest state.

That's the problem consistency is trying to prevent.

* * *

# And What About Availability?

Availability is a little different.

It basically asks:

> "If I send a request to a working server, will I get a response?"

Imagine one server has lost contact with another server.

If the application says:

> "Sorry, I can't do anything until the other server comes back."

then we've sacrificed availability.

On the other hand, if it says:

> "I'll give you the best information I currently have."

then we're keeping the system available, even if the information might temporarily be stale.

And this is exactly where the trade-off appears.

* * *

# Here's a Real Example: Social Media

Let's say you post:

> "I got a new job!"

Your post has to be distributed across multiple servers.

Now imagine there's a temporary network problem.

Your friend opens the app.

You might think:

> "My friend should immediately see my post."

But what if they don't?

Maybe the server handling your friend's request hasn't received the update yet.

Your friend refreshes.

Still nothing.

A few seconds later, they refresh again.

There it is.

Would that be annoying?

Yes.

Would it be the end of the world?

Probably not.

I'd much rather have:

> "Your feed is a few seconds behind."

than:

> "The entire application is unavailable."

This is why some systems are willing to tolerate temporary inconsistency in exchange for staying available.

* * *

# But What If the Data Is Extremely Important?

Now change the situation.

Imagine there's **only one concert ticket left**.

```text
Tickets remaining = 1
```

Two users are connected to two different servers.

```text
User A → Server A

User B → Server B
```

And then the network between the servers breaks.

Both servers still think:

```text
Tickets remaining = 1
```

User A buys the ticket.

Server A thinks:

```text
Tickets remaining = 0
```

But Server B doesn't know this happened.

User B also tries to buy the ticket.

Server B thinks:

```text
Tickets remaining = 1
```

If the system simply keeps accepting requests, both users might get the same ticket.

That's obviously a problem.

In this kind of situation, we may prefer the system to say:

> "I can't confirm your purchase right now."

rather than:

> "Congratulations! You both bought the last ticket."

So here, temporarily sacrificing availability can be preferable to allowing inconsistent decisions.

* * *

# And This Is Why CAP Is Not Just "Pick Any Two"

You've probably seen this diagram:

```text
          Consistency
             /\
            /  \
           /    \
          /      \
         /        \
        /__________\
Availability      Partition
```

And people often say:

> "CAP means you can choose any two."

It's a useful way to introduce the concept, but it's not the best way to actually understand it.

The real question is:

> **What does your system do when a network partition happens?**

Because when everything is working normally, you don't necessarily have to choose between consistency and availability.

The problem appears when:

```text
Server A   X   Server B
```

They can't communicate.

Now you have to decide:

> "Do I keep answering requests even though I might not have the latest information?"

or:

> "Do I stop/delay some requests until I can safely coordinate with the other side?"

That's the real CAP problem.

* * *

# A Little History

The name CAP comes from computer scientist **Eric Brewer**.

In 2000, Brewer presented the idea at the ACM Symposium on Principles of Distributed Computing.

At that point, it was a **conjecture**, not yet a formally proven theorem.

Then, in 2002, **Seth Gilbert and Nancy Lynch** published a formal proof showing that the fundamental trade-off Brewer described does hold.

That's why today we call it the **CAP Theorem**

* * *

# What About Eventual Consistency?

Here's another idea you'll often encounter around CAP.

Suppose we have three servers:

```text
Server A → ₹50
Server B → ₹100
Server C → ₹100
```

For a short period, they're not agreeing.

But the network comes back.

The update spreads:

```text
Server A → ₹50
Server B → ₹50
Server C → ₹50
```

Eventually, everyone agrees again.

That's the basic idea of **eventual consistency**.

The system basically says:

> "I don't promise that everyone will know the latest information immediately, but if things settle down, everyone will eventually catch up."

For things like social feeds, counters, recommendations, and other systems where a small delay is acceptable, this can be a very useful approach.

* * *

# So What's the Actual CAP Theorem?

After all these examples, we can finally state it simply.

**The CAP Theorem says that when a network partition occurs in a distributed system, you cannot simultaneously guarantee both strong consistency and availability.**

That's it.

Not:

> "CAP means three databases."

Not:

> "CAP means every system has to pick two."

And definitely not something that needs to be memorized without understanding what is happening.

Just remember this situation:

```text
             NETWORK BREAKS
                  ↓
       Server A  ✕  Server B
                  ↓
        They can't communicate
                  ↓
        ┌─────────┴─────────┐
        ↓                   ↓
   Keep responding      Stop / wait
        ↓                   ↓
   Availability         Consistency
```

If you keep responding, you may have to accept that different parts of the system can temporarily have different information.

If you want to guarantee that nobody acts on potentially stale information, you may have to reject or delay some requests.

And that's the trade-off