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 explains what happens when the network breaks. PACELC explains the cost of everyday operation: even without partitions, a distributed system still chooses between lower latency and stronger consistency.
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 explains a rare but painful moment: what happens when the system loses network connectivity between nodes. PACELC adds what happens every day, when engineers still need to decide whether to wait for extra coordination or return a faster answer with softer guarantees.
Key insight
Eventual consistency is often chosen not only as a failure strategy, but also as a way to reduce steady-state latency, avoid extra synchronous coordination, and sustain higher request throughput.
System classes under PACELC
PACELC splits systems into four classes based on two decisions: what to do during a partition and how to behave in ordinary operation.
How to read PACELC categories
PA/EL - Availability and lower latency
These systems keep serving requests through partitions and optimize for lower latency in normal operation. The cost is weaker consistency and more tolerance for temporary replica divergence.
PC/EC - Strong consistency in every mode
These systems preserve consistency both during partitions and in normal operation. That means more coordination, higher latency, and sometimes rejecting operations when the cluster cannot stay aligned.
PA/EC - Available during faults, stricter in normal operation
This class aims to stay available during partitions while leaning toward stronger guarantees when the network is healthy. It is useful when response time matters, but the team still wants to limit stale reads and conflict handling.
PC/EL - Strict under faults, fast in steady state
Under partitions these systems protect consistency, but in ordinary operation they try to keep latency low and avoid unnecessary coordination cost. It is a rarer but very illustrative PACELC position.
How the theorem emerged
In 2010, Daniel Abadi proposed PACELC as a response to the limits of CAP: a partition-time model alone is not enough if you also want to explain the cost of ordinary distributed-database operation. The idea was articulated 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 describes a choice between latency and consistency, but the word "consistency" hides several very different guarantees. Jepsen helps make that landscape explicit, from weaker convergence models up to linearizability and stronger transactional behavior.
Jepsen and consistency models
Consistency hierarchy, serializable vs linearizable behavior, and practical testing under failure
What to remember
- PACELC does not replace CAP; it adds the steady-state decision that CAP leaves out.
- Eventual consistency is often chosen to reduce latency, not only to survive failures.
- PA/EL fits products that prioritize response time and availability, while PC/EC fits domains that need stricter correctness.
- The right class depends on domain invariants, geography, replication strategy, and the cost of coordination.
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 - Practical context for how latency-versus-consistency choices shape high-load architecture decisions.
- 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.