CAP Theorem
In any distributed system, you can guarantee at most two of Consistency, Availability, and Partition Tolerance simultaneously.
What is the CAP theorem?
The CAP Theorem, proved by Eric Brewer in 2000, states that a distributed data store can guarantee at most two of three properties simultaneously:
- Consistency (C) - Every read receives the most recent write or an error. All nodes see the same data at the same time.
- Availability (A) - Every request receives a non-error response, though it may not be the most recent data.
- Partition Tolerance (P) - The system continues operating even when network partitions (message loss or delay between nodes) occur.
Why P Is Non-Negotiable
Network partitions happen in any real distributed system - cables fail, switches drop packets, data centers lose connectivity. You cannot design them away. This means the real engineering choice is always CP vs AP, not a free pick of two.
- CP systems prioritise consistency. When a partition occurs, they refuse requests rather than serve stale data. Examples: HBase, Zookeeper, etcd, MongoDB (with majority writes).
- AP systems prioritise availability. When a partition occurs, they continue serving requests with potentially stale data and reconcile later. Examples: Cassandra, DynamoDB (default), CouchDB, Riak.
Real-World Examples
| System | CAP Choice | Why |
|---|---|---|
| Cassandra | AP | Availability matters more than per-node consistency; eventual consistency acceptable |
| HBase | CP | Built on HDFS/ZooKeeper; correctness over availability |
| etcd | CP | Used for Kubernetes leader election - stale data would be catastrophic |
| DynamoDB | AP (default) | Tunable: strongly consistent reads available at 2× cost |
| PostgreSQL single-node | CA | Not distributed - partition tolerance not applicable |
The PACELC Extension
CAP only describes behaviour during partitions. PACELC extends it: even when the network is healthy (Else), there is a tradeoff between Latency (L) and Consistency (C). A system like DynamoDB is classified as PA/EL - it sacrifices consistency during partitions AND optimises for low latency at the cost of consistency during normal operation.
When to Apply
Use CAP reasoning when choosing a data store or designing replication strategy:
- Financial transactions, inventory counts, leader election -> prefer CP
- Social feeds, shopping carts, DNS, analytics -> prefer AP
- Never assume you can avoid partitions in production
Interview Angle
Interviewers expect you to know that P is non-negotiable. The follow-up question is almost always: "So when would you choose CP over AP in your design?" Anchor your answer to business requirements - what happens if users see stale data? What happens if the system is unavailable? That tradeoff drives the choice.