What is the PACELC theorem and how does it extend CAP?
PACELC says: if there is a Partition, choose Availability or Consistency; Else, when running normally, choose between Latency and Consistency. It captures that consistency costs latency even when nothing is broken.
Explain it simply
CAP only talks about the rare moment of a partition. But most of the time the network is fine, and designers still face a trade-off: to be strongly consistent, a write must reach several replicas before you reply, which takes longer. To reply fast, you answer after one replica and sync the rest later, which risks stale reads.
PACELC reads as two questions:
- If Partition: Availability or Consistency? (this is CAP)
- Else: Latency or Consistency?
Systems get labels like PA/EL (available in partitions, low latency otherwise, consistency relaxed both ways) or PC/EC (always favour consistency, paying in latency).
The theorem is useful in interviews because it explains why even a healthy cluster has a tunable dial. Many stores let you set this per query, such as requiring a quorum of replicas for a read.
Example
Replicas in Mumbai, Singapore and London; a write happens in Mumbai.
EC (consistent): wait for all three to acknowledge.
Latency = slowest link, say 180 ms.
EL (fast): acknowledge after Mumbai alone.
Latency = 5 ms, but a London read right
after may return old data.What to say in the interview
"PACELC extends CAP: during a partition choose A or C, otherwise choose between latency and consistency. It shows the consistency cost is paid every day, not only during failures. For a feed I would pick the low-latency side; for a ledger I would accept extra latency for consistency."
Common mistakes
- Treating the 'Else' half as an afterthought; it is the part that applies almost always.