concept
CAP Theorem
CAP Theorem
A 2000 result by eric-brewer|Eric Brewer stating that a distributed data store cannot simultaneously guarantee Consistency, Availability, and Partition tolerance — under a network partition you must give up one of C or A.
The classic framing (and why it’s misleading)
The interview-cliché version: draw a triangle, pick two corners, label your system.
| Corner | Meaning | Examples |
|---|---|---|
| CP | Consistency over availability when nodes can’t agree — wrong answer worse than no answer | Zookeeper, etcd, HBase |
| AP | Stay available during a partition, serve stale data, reconcile later | Cassandra (default) |
| CA | ”Pick a side” once partition tolerance is dropped — only makes sense for single-node systems | Postgres on one server |
Brewer himself called this framing misleading in his 2012 follow-up paper. Three specific problems:
- Properties are not binary. Availability is a spectrum (99.9 / 99.95 / 99.99), consistency is a spectrum (linearizable → eventual), and even “partition” depends on your timeout. Real systems live inside the triangle, not at the corners.
- It only describes partition behavior. Partitions are rare; the framework says nothing about what to optimize for the rest of the time. See pacelc for the extension that fixes this.
- The “CA” corner is incoherent for distributed systems. Networks fail. Labeling a multi-node system “CA” doesn’t change physics — it just means you’ll make partition decisions under pressure instead of deliberately.
Brewer’s 2012 reframing
“Maximize both C and A during normal operation, make a tradeoff only when a partition is actually detected.”
CAP becomes a runtime decision, not a permanent identity. The architecture work is in three-state design: see partition-mode-design.
Latency is the missing dimension
CAP says nothing about latency, but every distributed-system tradeoff (Cassandra consistency levels, MongoDB read preferences, DynamoDB strongly-consistent reads at 2× cost) is really a latency-vs-consistency decision. Daniel Abadi formalized this in pacelc (2010 blog / 2012 paper).
When the question goes away
Some data types sidestep CAP entirely. crdt|CRDTs guarantee convergence under any order of concurrent updates — no coordination needed. For cross-service workflows where you can’t avoid the tradeoff, the saga-pattern is the formal answer: accept the operation, bound the risk, log it, compensate on failure.
For systems where partition is the default state, see local-first-software.
See also
- pacelc — adds the latency dimension
- partition-mode-design — Brewer’s three-state architecture
- crdt — eliminate the tradeoff for certain data types
- saga-pattern — accept-bound-log-compensate for cross-service ops
- local-first-software — partition mode as the default state
- eric-brewer — author of the theorem and the 2012 revision