CAP Theorem: What It Actually Says (and What It Doesn't)
Consistency, Availability, Partition-tolerance — pick two. That summary is almost useless. Here's the real version.
CAP is the most-cited and most-misquoted theorem in distributed systems. The real statement: during a network partition, a system must choose between responding consistently or responding at all. Outside of a partition, you get both.
The three letters
- C — Consistency (linearizability). Every read sees the most recent committed write. Not the same as ACID's C.
- A — Availability. Every non-failing node responds to every request (with a non-error answer).
- P — Partition tolerance. The system keeps working when the network drops messages between nodes.
The "pick two" is misleading
You don't get to opt out of P. Networks partition. Cables fail, switches reboot, cloud zones lose connectivity. So in practice: when a partition happens, do you want the C or the A behaviour?
- CP systems (Postgres with sync replication, etcd, ZooKeeper, HBase) — during a partition the minority side stops accepting writes. You'd rather return an error than a stale answer.
- AP systems (Cassandra, DynamoDB in default mode, Riak) — during a partition both sides keep serving. You'll reconcile divergent writes later.
Outside of partitions: PACELC
The more complete framing (Abadi, 2012): If there's a Partition, trade Availability vs Consistency; Else trade Latency vs Consistency. Most "eventually consistent" stores are PA/EL — they accept latency cost in exchange for availability under partition and lower latency when healthy.
Practical consequences
- Choosing a database is choosing a partition behaviour. Read the docs, not the marketing page.
- Quorum configs (e.g.
W=2, R=2, N=3in Dynamo-style systems) let you tune where on the spectrum you sit — per-operation, even. - "Eventually consistent" does not mean "soon." It means "correct after the partition heals, assuming no new conflicts." Application code must handle reading its own stale writes.
The rule of thumb
Financial, inventory, correctness-critical → CP. Shopping carts, social feeds, analytics → AP. Mixed workload → two databases, one for each property, with clean boundaries. Don't fight a database's native behaviour.