📐 CAP Theorem

The Remote Team Analogy

Imagine a team split between New York and London, both maintaining customer records.

Suddenly, the internet connection between offices goes down (partition!).

You have three choices:

1. Stop working until connection restored (choose Consistency over Availability)
2. Keep working independently and merge later (choose Availability over Consistency)
3. Not split the team in the first place (give up Partition Tolerance)

You can't have all three during a network partition.

The Three Properties

C - Consistency

In CAP discussions, “Consistency” usually refers to a very strong consistency model (often described as linearizability): reads behave as if there is a single, up-to-date copy of the data.

Note: there are many consistency models. CAP’s trade-off is typically discussed using a strong one.

A - Availability

Every request to a non-failing node gets a response.

Important: “availability” doesn’t mean “success.” A system can be available but respond with an error if it chooses to preserve consistency.

P - Partition Tolerance

System continues operating despite network failures between nodes (dropped/delayed messages).

The Theorem

"When a network partition happens, a distributed system has to trade off between Consistency and Availability."

When a network partition happens, you're really choosing between:

• CP: Consistent, but may be unavailable during partition
• AP: Available, but may return stale data during partition

Visual Representation

        Consistency
           /\
          /  \
         /    \
        / CP   \
       /________\
      /    CA    \
     /_____  _____\
    Partition    Availability
    Tolerance
         \ AP /
          \  /
           \/

Real Database Examples

Practical Intuition

Instead of memorizing which specific product is “CP” or “AP” (it often depends on configuration), focus on the behavior you want during a partition:

• CP-style behavior: reject or block some operations so the system doesn’t return potentially inconsistent results.
• AP-style behavior: keep responding, even if some responses might be stale or conflicting until the partition heals.

Many systems are tunable: you can choose stronger consistency for some operations (at the cost of availability/latency) and looser consistency for others.

Real-World Scenarios

Scenario 1: E-commerce Inventory

Two data centers: East and West
Network partition occurs
Customer sees "5 items in stock" (stale data)
Both centers sell the last item
Result: Oversold!

Choice: CP system - better to show "temporarily unavailable" than oversell.

Scenario 2: Social Media Likes

Network partition occurs
User A sees 100 likes
User B sees 102 likes
Different but both "correct" at that moment

Choice: AP system - showing slightly different counts is fine.

Scenario 3: Banking

Transfer money: NYC → London
Network partition during transfer

Choice: CP - block the transfer rather than risk inconsistency.

Common Misconceptions

"Pick 2" Is Misleading

In practice, partitions are temporary. You choose behavior DURING partitions:

• Normal operation: All three properties can coexist
• During partition: Choose C or A

"NoSQL = AP, SQL = CA"

Not necessarily true. Many NoSQL databases offer tunable consistency.

Many systems let you tune the trade-off per operation.

PACELC Extension

CAP only describes partition scenarios. PACELC adds:

If Partition (P), choose Availability or Consistency. Else (E), choose Latency or Consistency.

Even without partitions, there's a latency vs consistency trade-off.

Note: PACELC is a helpful extension, but it’s a model/heuristic rather than a law like CAP.

FAQ

Q: Can I have all three?

Not during a network partition. But partitions are rare, so normally you can have all three.

Q: Which should I choose?

Depends on your use case:

• Financial data: CP
• Social features: AP

Q: How do I know if my database is CP or AP?

Check documentation. Many databases let you configure this per-operation.

Q: Does CAP apply to microservices?

Yes! Any distributed system faces these trade-offs.

Q: What about "eventually consistent"?

That's an AP-style choice during partitions: prioritize availability, and let replicas converge later.

Q: How rare are partitions?

In cloud environments, more common than you'd think. Network issues happen.

Summary

CAP Theorem states distributed systems must choose between Consistency and Availability during network partitions.

Key Points:

• You can only prioritize 2 of 3 during partitions
• CP: Consistent but may be unavailable
• AP: Available but may be stale
• Choice depends on your application's needs
• Most databases let you configure this trade-off