What About When Things Are Working?
The CAP theorem is essential, but it only describes behavior during failures — when there is a network partition. What about the other 99.9% of the time when the network is fine?
Consider this: if you want extremely strong consistency, every write must be replicated to multiple nodes before you tell the client "success." That replication takes time — milliseconds, but measurable milliseconds. A user in New York writing to a database that must synchronously confirm with a replica in London will wait for the speed of light across the Atlantic. This latency cost exists even when nothing is broken.
This realization led computer scientist Daniel Abadi to formulate the PACELC Theorem in 2012, which extends CAP to cover normal operation:
If there is a Partition, how does the system trade off Availability and Consistency?
Else (when the system is running normally), how does the system trade off Latency and Consistency?
The Full Picture
PACELC forces you to answer two distinct questions about your database:
- During a partition: Do I want to stay up (AP) or stay correct (CP)?
- During normal operation: Do I want to be fast with low latency (EL) or completely correct every millisecond (EC)?
This gives us four possible classifications:
| Classification | Partition Behavior | Normal Behavior | Example Systems |
|---|---|---|---|
| PA/EL | Available | Low Latency | Cassandra, DynamoDB |
| PC/EC | Consistent | High Consistency | etcd, HBase, VoltDB |
| PA/EC | Available | High Consistency | Rare; complex to implement |
| PC/EL | Consistent | Low Latency | Rare; contradictory goals |
The key insight PACELC adds: you cannot have low latency AND strong consistency simultaneously, even when the network is perfect. Synchronous replication to achieve consistency always costs latency. This is a physical constraint, not an engineering limitation.
When asked "what is the difference between CAP and PACELC?", the answer is: CAP only describes trade-offs during failure scenarios (partitions). PACELC extends this by also describing the latency-vs-consistency trade-off during normal operation. PACELC is strictly more informative — it tells you how a system behaves both when things break and when things work.