CAP answers the failure question. PACELC explains normal life. That is what makes it genuinely useful: most of the time, the system is paying for the everyday balance between latency and consistency, not for partition itself.
In practice, this chapter helps separate steady-state policy from failure-mode policy so teams do not make the exact same design choice for the happy path and for a network that is already breaking down.
In interviews and architecture reviews, it gives you a more mature language: tail latency, conflict probability, reconciliation cost, and the reason a system can be expensive or slow even when nothing is visibly on fire.
Practical value of this chapter
Design in practice
Extends CAP reasoning to steady-state operation, not only partition scenarios.
Decision quality
Supports separate policies for normal mode and failure mode behavior.
Interview articulation
Strengthens answers by comparing latency/consistency strategies in context.
Risk and trade-offs
Makes trade-off costs explicit: tail latency, conflict probability, and reconciliation complexity.
Original
Telegram: book_cube
Original post with analysis of the PACELC theorem.
The CAP theorem explains the behavior of a system during network failures. But what happens when everything works fine? The PACELC theorem extends CAP and describes the tradeoffs of distributed systems during normal operation.
Related chapter
CAP theorem
Fundamental limitation of distributed systems.
Statement of the theorem
if P then (A or C) else (L or C)
PACELC formula
If a network split occurs, the system chooses between:
In normal mode, the system chooses between:
Foundation
HTTP protocol
Protocol-level latency affects the L vs C tradeoff.
Why is PACELC needed?
The CAP theorem does not explain why systems like Amazon Dynamo or Cassandra choose eventual consistency. After all, network divisions are rare. Real reason:
Key insight
Eventual consistency is used not only in case of accidents, but also for reducing delays in daily work. This is the “L over C” choice in the “Else” part of the PACELC theorem.
System classification
PACELC gives four categories of systems depending on their choice in each situation:
Detailed analysis of categories
PA/EL - Speed comes first
Systems in this category sacrifice strict consistency for speed and reliability. In partition, availability is selected; in normal mode, minimum delays are selected.
PC/EC - Consistency at any cost
Always choose consistency. With partition they can refuse service; in normal mode they are ready to endure high delays for the sake of consistency.
PA/EC - Hybrid Approach
In case of failures, they maintain availability, but in normal mode they strive to ensure consistency. A trade-off between reliability and correctness.
PC/EL - Severity in case of failures, speed is normal
With partition, they choose consistency (they may fail), but in normal mode they work as quickly as possible, allowing for temporary inconsistency.
Story
Theorem proposed Daniel Abadie (Daniel Abadi) in the article "Consistency Tradeoffs in Modern Distributed Database System Design".
Trade-off visualization
Latency vs Consistency Trade-off
Interactive chart showing how distributed systems are positioned.
Systems in the lower-left prioritize response speed and allow temporary replica divergence.
Systems in the upper-right guarantee consistency, paying with higher latency due to synchronization.
Disclaimer: System positions on this chart are qualitative estimates, not exact measurements. Real characteristics depend on configuration, workload, version, and network conditions.
The PACELC classification is based on Daniel Abadi’s paper "Consistency Tradeoffs in Modern Distributed Database System Design" (2012) and widely accepted industry classification.
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 |
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 Whole Picture
PACELC talks about choosing between Latency and Consistency, but what exactly is meant by "consistency"? Project Jepsen created a complete hierarchy of models showing how transactional isolation (RDBMS) and linearizability (distributed systems) converge at the top.
Jepsen and consistency models
Hierarchy of consistency models, Serializable vs Linearizable, testing distributed systems
Key Findings
- PACELC explains the choice of eventual consistency in systems like Dynamo - it's not just about accidents
- Latency vs Consistency - a key trade-off for highly loaded systems in normal mode
- Most NoSQL databases are PA/EL, most traditional DBMSs are PC/EC
- The choice of category depends on business requirements: finance requires PC/EC, social networks - PA/EL
Related chapters
- Why distributed systems and consistency matter - Section entry map and baseline context for consistency, availability, and latency trade-offs.
- CAP theorem - Foundational model for behavior under network partitions that PACELC extends for normal operation.
- Scalable system design principles - Practical context for latency vs consistency trade-offs in high-load architecture decisions.
- Jepsen and consistency models - Detailed hierarchy of consistency models and methods to validate real distributed-system behavior.
- Designing Data-Intensive Applications (short summary) - Deep source on replication, consistency, and production trade-offs in distributed data systems.
- Database Internals: A Deep Dive (short summary) - How engine internals and replication mechanisms realize PACELC trade-offs in implementation.
- Cassandra: The Definitive Guide (short summary) - Practical PA/EL-class example with tunable consistency and explicit latency-availability controls.
- Guide to Databases (short summary) - Broad overview of storage options and selection criteria under consistency and latency constraints.
- Multi-region / Global Systems - Global topologies, cross-region replication, and real-world latency-consistency operating constraints.