CAP explains what happens during failure. PACELC explains the price of normal life. That is what makes it so practical: most of the time, the system is paying for the everyday balance between latency and consistency, not for the partition itself.
In practice, this chapter helps separate steady-state policy from degradation policy so teams can reason differently about fast responses and about what should happen when connectivity starts to break.
In interviews and architecture reviews, it gives you a more mature language for tail latency, conflict probability, coordination cost, and the price of reconciling replicas after the fact.
Practical value of this chapter
Design in practice
Extends CAP reasoning into steady-state operation instead of stopping at partition scenarios.
Decision quality
Helps define separate policies for ordinary behavior and for network-failure behavior.
Interview articulation
Strengthens answers by comparing strategies through coordination cost, response time, and acceptable divergence.
Risk and trade-offs
Makes the price of each choice explicit: tail latency, conflict probability, and reconciliation complexity.
Original
Telegram: Book Cube
Original post discussing the PACELC theorem.
CAP names the rare, painful moment when the network breaks. PACELC names the cost of every other day: even with a healthy network a distributed system still decides between lower latency and stronger consistency on every write and read.
Related chapter
CAP theorem
Fundamental limitation of distributed systems.
What the PACELC theorem says
if P then (A or C) else (L or C)
PACELC formula
If the network splits, the system must choose between:
When the network is healthy, the system chooses between:
Foundation
HTTP protocol
Protocol-level latency affects the L vs C tradeoff.
Why the PACELC theorem matters
CAP captures a rare, painful moment: connectivity between nodes is gone. PACELC adds the everyday case — with a healthy network the engineer still decides whether to wait for extra coordination and a stricter answer, or reply faster with softer guarantees.
Key insight
Eventual consistency is not just a failure strategy. More often it is picked to reduce steady-state latency, cut synchronous coordination, and sustain higher request throughput.
System classes under PACELC
Every system answers two questions: which way to lean under a partition, and at what price to hold a response in steady state. The intersection produces four PACELC classes.
How to read PACELC categories
PA/EL - Availability and lower latency
Requests have to keep flowing under partitions and answer as fast as possible in steady state. The price — weaker guarantees and temporary replica divergence the product has to live with at the application layer.
PC/EC - Strong consistency in every mode
Consistency holds at all times — both under partitions and in calm operation. The bill comes as longer coordination, more synchronization, and sometimes rejected operations the moment the cluster cannot stay aligned.
PA/EC - Available during faults, stricter in normal operation
A balance between two priorities: stay available when the network splits, hold stronger guarantees when it is healthy. Fits products where response time matters but the team will not accept stale reads and conflict resolution as the norm.
PC/EL - Strict under faults, fast in steady state
A mirror of the previous class: under partitions the system protects consistency, in everyday operation it cuts latency and refuses to pay for unnecessary synchronous coordination. A rare but very telling angle on the trade-off.
How the theorem emerged
In 2010, Daniel Abadi proposed PACELC to close a blind spot in CAP: a partition-time model alone is not enough if you also have to explain the cost of ordinary distributed-database operation. The core idea is laid out in the paper "Consistency Tradeoffs in Modern Distributed Database System Design".
Visualizing the latency-consistency trade-off
Latency vs consistency trade-off
Interactive chart showing how real systems sit along the PACELC spectrum.
Systems in the lower-left prioritize response speed and tolerate temporary divergence between replicas.
Systems in the upper-right preserve stronger guarantees, paying for them with extra coordination and latency.
Important: System positions on this chart are qualitative estimates, not exact measurements. Real characteristics depend on configuration, workload, version, and network conditions.
The PACELC classification here is grounded in Daniel Abadi’s paper "Consistency Tradeoffs in Modern Distributed Database System Design" and on widely accepted industry interpretations.
Classification sources
| Database | Category | Source |
|---|---|---|
Cassandra | PA/EL | Apache Docs |
DynamoDB | PA/EL | AWS Docs |
Riak | PA/EL | Riak Blog |
CouchDB | PA/EL | CouchDB Docs |
Redis Cluster | PA/EL | Redis Docs |
Voldemort | PA/EL | Voldemort Design |
ScyllaDB | PA/EL | ScyllaDB Docs |
MongoDB | PA/EC | MongoDB Docs |
Cosmos DB | PA/EC | Azure Docs |
Firebase RTDB | PA/EC | Firebase Docs |
PNUTS | PC/EL | VLDB Paper |
| Database | Category | Source |
|---|---|---|
HBase | PC/EL | HBase Book |
FoundationDB | PC/EL | FDB Docs |
VoltDB | PC/EC | VoltDB Docs |
Spanner | PC/EC | Google Cloud |
CockroachDB | PC/EC | CRDB Docs |
YugabyteDB | PC/EC | YugabyteDB Docs |
TiDB | PC/EC | TiDB Docs |
PostgreSQL | PC/EC | PostgreSQL Docs |
MySQL Cluster | PC/EC | MySQL Docs |
Megastore | PC/EC | Google Research |
More details
Jepsen and consistency models
Complete hierarchy of consistency models from the Jepsen project.
Consistency models: the bigger picture
PACELC sets the latency-vs-consistency axis, but the word "consistency" hides a whole stack of guarantees. Jepsen sorts them out: where eventual consistency ends, where strong consistency begins, and how linearizability and stronger transactional behavior sit above the weaker convergence models.
Jepsen and consistency models
Consistency hierarchy, serializable vs linearizable behavior, and practical testing under failure
What to remember
- PACELC does not replace CAP — it extends it into steady state, where the trade-off persists even with a healthy network.
- Eventual consistency is more often chosen to cut steady-state latency than to survive a failure.
- PA/EL fits products that prioritize response time and availability, while PC/EC fits domains that need stricter correctness.
- The final class is decided by domain invariants, geography, replication strategy, and coordination cost — not by team preference.
Related chapters
- Why distributed systems and consistency matter - Section entry point for reasoning about invariants, consistency boundaries, and partial failure before choosing an architecture.
- CAP theorem - The partition-time model that PACELC builds on and extends into steady-state operation.
- Scalable system design principles - Where the latency-versus-consistency trade-off starts driving the architecture of a high-load system as it grows.
- Jepsen and consistency models - Detailed map of consistency models and ways to verify which guarantees a distributed system actually provides.
- Designing Data-Intensive Applications, 2nd Edition (short summary) - Deep source on replication, consistency, and architectural trade-offs in real distributed data systems.
- Database Internals: A Deep Dive (short summary) - How storage internals and replication mechanics turn PACELC trade-offs into concrete system behavior.
- Cassandra: The Definitive Guide (short summary) - A practical PA/EL example with tunable consistency and explicit latency trade-offs under load.
- Guide to Databases (short summary) - Overview of storage options and selection criteria under consistency, latency, and availability constraints.
- Multi-region / Global Systems - Cross-region replication, global topologies, and the real operating cost of latency-consistency trade-offs.