The problem
When the network splits a distributed system in two, you can't have everything. What do you give up?
The idea
CAP: during a partition you must choose Consistency or Availability (you can't keep both). PACELC adds: Else (no partition), choose Latency or Consistency.
How it works
CP systems refuse writes on the minority side to stay consistent (e.g. a strongly-consistent store). AP systems keep serving and reconcile later (eventual consistency). PACELC notes that even without partitions, stronger consistency costs latency.
The tradeoff
CP = correct but can be unavailable; AP = always up but can be stale/conflicting. Choose per data: money = CP, likes = AP.
In the wild
DynamoDB (AP-leaning, tunable), Spanner (CP with clever clocks), ZooKeeper (CP).
Deep dive
Flow
- Name the data that must stay correct during a partition.
- Choose CP when wrong answers are worse than rejected writes.
- Choose AP when stale answers are acceptable and uptime wins.
- Explain the normal-case PACELC latency cost too.
Watch for
- CAP is only forced during partitions.
- "CA distributed database" is usually a red flag.
- Different features in one product can make different choices.
Common trap
Do not label the whole system CP or AP; label each critical data path.
Common questions
What problem does CAP & PACELC solve?
When the network splits a distributed system in two, you can't have everything. What do you give up?
How does CAP & PACELC work?
CP systems refuse writes on the minority side to stay consistent (e.g. a strongly-consistent store). AP systems keep serving and reconcile later (eventual consistency). PACELC notes that even without partitions, stronger consistency costs latency.
What are the tradeoffs of CAP & PACELC?
CP = correct but can be unavailable; AP = always up but can be stale/conflicting. Choose per data: money = CP, likes = AP.
Where is CAP & PACELC used in production?
DynamoDB (AP-leaning, tunable), Spanner (CP with clever clocks), ZooKeeper (CP).