What is the CAP Theorem?
The CAP theorem states that a distributed system can only guarantee two of the following three properties at the same time:
- Consistency — every read gets the latest write or an error
- Availability — every request gets a response (may be stale)
- Partition Tolerance — system works even when nodes can't communicate
Why You Can Only Pick Two
Network partitions are inevitable in distributed systems. The real choice is between Consistency and Availability when a partition occurs.
During a partition, you must choose:
- CP → Node B refuses to respond — sacrifices Availability
- AP → Node B returns stale data — sacrifices Consistency
CP vs AP Systems
CP — use when correctness is critical: bank transfers, inventory, leader election.
AP — use when availability matters more: social feeds, shopping carts, product catalogs.
Real Database Choices
| Database | Type | Reasoning |
|---|---|---|
| PostgreSQL | CP | Synchronous replication — consistency first |
| MongoDB | CP (default) | Primary-only reads by default |
| Cassandra | AP | Tunable consistency, defaults to availability |
| DynamoDB | AP (default) | Eventually consistent reads by default |
| Redis | CP | Single primary, replicas are async |
| Zookeeper | CP | Designed for coordination |
| CouchDB | AP | Designed for offline-first |
PACELC — The Full Picture
CAP only covers partition behavior. PACELC extends it to normal operation:
Key Takeaway
- Partition tolerance is mandatory — the real choice is C vs A
- CP → errors over stale data (banks, inventory)
- AP → stale data over errors (social feeds, carts)
- Most modern databases let you tune per operation