The CAP Theorem Explained: Why Distributed Systems Must Make Trade-offs
The CAP theorem, proven by Eric Brewer and Gilbert and Lynch in 2002, establishes a fundamental limit: when a network partition occurs, a distributed system must choose between returning a consistent answer and remaining available. Knowing this trade-off explains the design of every distributed database you will encounter.
Published June 30, 2026Every distributed system designer eventually asks: what happens when some nodes cannot reach others? The CAP theorem formalizes the answer into an unavoidable choice. CAP stands for Consistency, Availability, and Partition tolerance. The theorem says you can guarantee at most two of the three when a network partition is happening. In practice, because partitions happen in real networks whether you plan for them or not, the real choice is always between C and A.
What Each Property Means
Consistency (C) means that every read receives the most recent write or an error. If you write a value to node A and then read it from node B, you get the same value. This is sometimes called "linearizability" or "strong consistency." It is not the same as the C in ACID (which is about data integrity constraints, not distributed agreement).
Concrete example: you update your account balance to $1,000 on one node. A consistent system guarantees that any subsequent read from any node returns $1,000, not a stale value. If it cannot guarantee that, it returns an error rather than a stale answer.
Availability (A) means that every request receives a non-error response, though the response may be stale. The system stays online and responsive even if some nodes are unreachable. Availability does not mean "fast"; it means "returns a response."
Concrete example: a node that has been partitioned from the rest of the cluster still accepts reads and writes, returning the best data it has, even if that data may be out of date.
Partition tolerance (P) means the system continues operating even when network messages between nodes are dropped or delayed. A partition is when a network fault splits the cluster into groups that cannot communicate.
Why Partition Tolerance Is Not Optional
Networks fail. Cables are cut, switches malfunction, cloud availability zones lose connectivity to each other. A system that stops working entirely when a single packet is lost is not production-ready. Partition tolerance is therefore not a feature you choose; it is a property you must design for.
This reduces the CAP trade-off to a binary choice that matters only during a partition: do you return a potentially stale answer (AP) or return an error (CP)? When the partition heals, both AP and CP systems can converge on a consistent state. The trade-off only bites during the partition itself.
Real Systems and Their Choices
| System | CAP Classification | Behavior During Partition |
|---|---|---|
| Apache Zookeeper | CP | Rejects writes and some reads if quorum cannot be reached; prioritizes correctness over availability |
| etcd | CP | Uses Raft consensus; a minority partition becomes read-only and refuses writes |
| Apache Cassandra | AP (tunable) | Every node accepts writes; partitioned nodes diverge and reconcile with last-write-wins or vector clocks |
| CouchDB | AP | Accepts writes to partitioned nodes; reconciles conflicts at read time using MVCC |
| Single-node SQL (PostgreSQL, MySQL) | CA (single node) | No partitions possible within one node; CA is achievable but irrelevant to distributed deployments |
The PACELC Extension
CAP only describes behavior during a partition. Daniel Abadi proposed PACELC to capture the trade-off that exists even during normal operation: if there is a Partition (P), choose between Availability (A) and Consistency (C); Else (E), during normal operation, choose between Latency (L) and Consistency (C).
PACELC acknowledges that distributing data across nodes always introduces latency. A strongly consistent system must coordinate writes across replicas (adding round-trip time) even when there is no partition. Cassandra is PA/EL: it favors availability during partitions and low latency during normal operation. DynamoDB is PA/EL by default but configurable. Zookeeper is PC/EC: it prioritizes consistency both during and outside of partitions, at the cost of availability and latency.
Practical Takeaways
- You cannot choose CA for a system that communicates over a network. Network partitions happen. Design for P.
- The choice between CP and AP is driven by your application's tolerance for stale data. A bank ledger should be CP. A shopping cart recommendation engine can tolerate AP.
- AP systems require conflict resolution strategies: last-write-wins, vector clocks, CRDTs, or application-level merging. These are not free.
- Most systems offer tunable consistency. Cassandra's read and write consistency levels let you move between AP and CP on a per-request basis by controlling how many replicas must agree before returning success.
- CAP says nothing about performance. Both CP and AP systems can be fast or slow; the theorem only constrains behavior during partitions.