~100s Visual Explainer

CAP Theorem

Why distributed systems can't have Consistency, Availability, and Partition Tolerance all at once during network failures.

Based on: CAP Theorem Eventual Consistency Quorum
C Consistency A Availability P Partition Tolerance Same data everywhere Always responds Survives network splits Normal Operation Node 1 x = 5 Node 2 x = 5 replicating... Client writes x=5 All nodes consistent ✓ Network Partition! Node 1 x = 6 Node 2 x = 5 (stale) ✕ PARTITION Nodes cannot synchronize! Client reads from Node 2... The Impossible Choice Choose Consistency (CP) Node 2 UNAVAILABLE Client gets 503 Error No wrong data ✓ Choose Availability (AP) Node 2 x = 5 (old) Client gets stale data Always responds ✓ ? Real-World Choices CP: Consistency First 🔒 Banking transactions Inventory systems Distributed locks "Wrong data = real harm" AP: Availability First 🌐 Social media feeds Shopping carts DNS, CDNs "Stale data is acceptable" Ask: "What's worse—old data or no data?"
1 / ?

Three Desirable Properties

The CAP theorem (proven by Gilbert and Lynch in 2002) states that distributed systems cannot simultaneously guarantee all three properties:

  • Consistency: All nodes see the same data at the same time
  • Availability: Every request receives a response
  • Partition Tolerance: The system works despite network failures

CAP doesn't constrain trade-offs when there is no partition. The tension only emerges when the network splits.

When Everything Works

During normal operation, a distributed system can provide all three properties. Write to one node, replicate to others, and every node returns the latest value.

The magic breaks when the network breaks.

  • Replication keeps nodes in sync
  • Reads return consistent data from any node
  • No trade-off required when network is healthy

Network Partition Strikes

A network partition splits your cluster into groups that cannot communicate. This happens due to router failures, cable cuts, datacenter issues, or cloud provider problems.

During a partition, Node 1 accepts a write (x=6) but cannot replicate to Node 2 (still has x=5). Now the nodes disagree — this is called split-brain.

  • Partitions are inevitable, not exceptional
  • Split-brain: nodes have different views of data
  • The system must continue operating during partition

Choose: Consistency or Availability

When a client reads from Node 2 during the partition, the system faces an impossible choice:

  • Choose Consistency (CP): Refuse to respond until partition heals. Client gets an error, but never sees wrong data.
  • Choose Availability (AP): Return stale value x=0. Client gets a response, but it may be outdated.

You cannot have both — this is the CAP theorem. The partition forces the choice.

Systems Make Different Choices

The right choice depends on your domain:

  • CP (Consistency): When wrong data causes real harm — financial transactions, inventory counts, distributed locks.
  • AP (Availability): When stale data is acceptable — social media feeds, shopping carts, DNS, CDNs.

Ask yourself: "What's worse — showing old data or showing nothing?"

Note: Different parts of a system can make different choices. Your checkout might be CP while your product catalog is AP.

What's Next?

Now that you understand CAP theorem, explore related patterns: Eventual Consistency for how AP systems converge, Raft Consensus for how CP systems achieve agreement, or dive into Quorum mechanics.