Distributed Systems for Backend Engineers · Distributed Systems Fundamentals
CAP and PACELC
What the theorems really say and how to use them.
CAP: during a network Partition, a system must choose between Consistency (linearizability) and Availability (every non-failed node answers). It says nothing about normal operation. PACELC extends it: if Partitioned, choose A or C; Else (normal operation) choose between Latency and Consistency. Real systems make different choices per operation, and partitions are rare but must be designed for.
Systems through a PACELC lens
| System | During partition (PAC) | Normally (ELC) |
|---|---|---|
| Spanner / CockroachDB | Consistency (PC) | Consistency (EC) — higher latency |
| DynamoDB (default reads) | Availability (PA) | Latency (EL) — eventually consistent reads |
| Cassandra (tunable) | PA by default | EL; QUORUM reads/writes trade toward C |
| MongoDB (majority) | PC | EC with majority read/write concerns |
| etcd / ZooKeeper | PC (minority side unavailable) | EC |
Common pitfalls
- Saying 'we chose CA' (partitions aren't optional).
- Treating CAP as a general design rule instead of a partition-time trade-off.
- Ignoring the latency cost of consistency in normal operation.
Key points
- CAP only applies during partitions
- PACELC adds latency vs consistency
- Choose per operation
Further reading: Abadi: Consistency Tradeoffs in Modern Distributed Database System Design (PACELC)
Practice questions
Why is 'CA' not a meaningful choice for a distributed system?
Answer
Network partitions can always happen; the real choice is how the system behaves when they do (sacrifice consistency or availability).
What does the 'ELC' part of PACELC add?
Answer
Even without partitions, stronger consistency costs latency (coordination round trips), so systems trade latency against consistency in normal operation.
Open in the app to mark lessons complete, take notes and track your progress.