CAP Theorem

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

Read this as During a partition, which guarantee is allowed to bend?
Failure Trap
Treating CAP as a normal latency trade-off instead of a partition-time choice.
Decision Rule
Prefer CP when conflicting writes are worse than downtime; prefer AP when serving stale or reconciled data is acceptable.
CAP theorem trade-off A five-step diagram. A distributed system can hold Consistency, Availability, and Partition tolerance together while the network is healthy. When a network partition splits the nodes, the system must choose: stay consistent and reject requests (CP), or stay available and return stale data (AP). CAP trade-off C Consistency A Available P Partition Healthy = all 3. Split = pick C or A. Normal operation Node 1 x = 5 Node 2 x = 5 sync Nodes agree C + A + P hold Network partition Node 1 x = 6 Node 2 x = 5 stale Nodes cannot sync x=6  ≠  x=5 — split-brain Client now reads Node 2… Pick one (while split) CP: stay consistent Node 2 refuses to answer Client gets 503 error never wrong · sometimes down AP: stay available Node 2 answers its copy Client gets stale x = 5 always up · sometimes old Real systems choose CP: consistency first Banking · inventory · locks Wrong data = real harm AP: availability first Feeds · carts · DNS · CDNs Stale data is acceptable 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

The popular "pick 2 of 3" shorthand is misleading. Partition tolerance is not optional in a real distributed system — networks fail. CAP only forces a trade-off during a partition: at that moment you choose between Consistency and Availability. When the network is healthy, a system can deliver all three.

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 Node 2's stale value x=5. Client gets a response, but it is the old value (Node 1 already accepted x=6).

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.