CAP Theorem
The CAP Theorem (Brewer’s Theorem) states that a distributed database system can provide at most two out of three guarantees 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, without guarantee that it contains the most recent write.
- Partition Tolerance (P) — The system continues to operate despite network partitions (message loss or delay between nodes).
The Tradeoff
In any distributed system, network partitions will happen. So partition tolerance is not optional — the real choice is between consistency and availability during a partition:
| System Type | Guarantees | Sacrifices | Examples |
|---|---|---|---|
| CP | Consistency + Partition Tolerance | Availability during partition | MongoDB (strong consistency mode), HBase, Redis Cluster |
| AP | Availability + Partition Tolerance | Consistency (eventual) | Cassandra, DynamoDB, CouchDB |
| CA | Consistency + Availability | Partition Tolerance | Traditional [[Relational Model |
ACID vs BASE
The CAP Theorem directly motivates the distinction between ACID and BASE models:
- ACID — Prioritizes consistency. Used by traditional relational databases. Strong guarantees per transaction.
- BASE — Basically Available, Soft state, Eventually consistent. Trades consistency for availability. Common in NoSQL Databases and large-scale distributed systems.
Practical Implications
- Most modern systems are tunable — they let you choose consistency levels per query (e.g., Cassandra’s
ONE,QUORUM,ALLconsistency levels) - The PACELC extension adds: even when there is no partition (E), there’s a tradeoff between latency and consistency
- Two-Phase Commit (2PC) provides strong consistency in Distributed Databases at the cost of availability