System Design Foundations
CAP Theorem
During a network partition, a distributed system must choose between Consistency and Availability — it cannot have both. Outside a partition, both are attainable; CAP is a statement about behavior under failure, not a permanent label.
- CAP: Consistency (every read sees the latest write), Availability (every request gets a non-error response), Partition tolerance (the system keeps working despite dropped/delayed messages between nodes)
- Partition tolerance is not really optional for a system spanning more than one machine — networks partition — so CAP in practice is a choice between C and A during a partition
- CP systems (e.g. ZooKeeper, HBase, etcd): a minority partition refuses to serve reads/writes rather than risk returning stale or conflicting data
- AP systems (e.g. Cassandra, DynamoDB): every partition keeps serving, accepting that replicas may diverge until reconciled afterward
- PACELC extends CAP: Else (no partition), there is still a tradeoff between Latency and Consistency — coordinating for strong consistency costs latency even when nothing is broken
| CP (consistency-first) | AP (availability-first) | |
|---|---|---|
| Behavior under partition | Minority side refuses requests | Both sides keep serving |
| Data risk | None — no divergence allowed | Divergent writes, reconciled later |
| Examples | ZooKeeper, etcd, HBase | Cassandra, DynamoDB, Riak |
| Good fit | Configuration, leader election, financial ledgers | Shopping carts, social feeds, presence status |