CAP Theorem

Distributed Systems

The CAP theorem says you can’t have everything in a distributed system. Pick two: consistency, availability, or partition tolerance.

Consistency means all nodes see the same data at the same time. After a write, every read reflects it.

Availability means the system responds to requests, even if some nodes are down.

Partition tolerance means the system keeps working even when network failures split nodes apart.

The theorem says: when a network partition happens (and it will), you have to choose between consistency and availability. You can’t have both.

In practice, partition tolerance isn’t optional - networks fail. So the real choice is CP or AP:

  • CP systems (consistency + partition tolerance): When a partition happens, the system might refuse requests rather than return stale data. Think databases where correctness matters more than uptime - HBase, MongoDB in certain configs.

  • AP systems (availability + partition tolerance): When a partition happens, nodes keep serving requests even if they might be out of sync. They’ll reconcile later. Cassandra, DynamoDB, DNS.

The tricky part is that CAP is about behavior during a partition. When the network is healthy, you can have all three. The theorem only forces a choice when things go wrong.

Also worth noting: “consistency” in CAP means linearizability (strong consistency), not eventual consistency. Many systems live somewhere in between, accepting some staleness for better availability.