PACELC — what it adds to CAP
CAP only tells you what happens during a partition — a rare event. PACELC, introduced by Daniel Abadi in 2012, extends it to cover the common case: normal operation, when there is no partition. That makes it the more practically useful framing for choosing a data store.
The formulation
If there is a Partition, choose between Availability and Consistency; Else (no partition), choose between Latency and Consistency.
+-- Partition (P) -----> choose A or C
PACELC --------|
+-- Else (E) -----> choose L or C
Why the "else" branch matters more
Partitions are infrequent; the latency-vs-consistency trade-off, by contrast, is paid on every single request. Strong consistency (linearizability) requires coordination — a write must reach a quorum or the leader before it's acknowledged, which costs round trips. If you instead allow asynchronous replication and serve from the nearest replica, you get lower latency but weaker consistency (a read might miss a recent write). PACELC names this everyday tension that CAP ignores entirely.
Classifying real systems
Each system gets a two-part label: its partition behavior, then its normal-operation behavior.
| System | Partition (P) | Else (E) | Label | Reading |
|---|---|---|---|---|
| DynamoDB / Cassandra (default) | A | L | PA/EL | Availability under partition; low latency otherwise |
| Cassandra tuned to QUORUM | A | C | PA/EC | Available under partition, but pays latency for consistency normally |
| Single-leader RDBMS (sync replication) | C | C | PC/EC | Consistent always, at a latency cost |
| MongoDB (default) | C | C | PC/EC | Rejects writes without primary; reads from primary |
| MongoDB (read from secondaries) | C | L | PC/EL | Consistent under partition, low latency reads otherwise |
How to use it in a design
When you choose a store, narrate both branches: "Under a partition I'm fine serving stale data here (PA), and in normal operation I'll take the low-latency, eventually-consistent read (EL), because this is a feed and staleness of a few hundred milliseconds is invisible." Conversely, for a payment ledger: "PC/EC — I'll pay the coordination latency because I can never serve a wrong balance." This is the framing DDIA Chapter 9 points toward when it argues CAP alone is too coarse for real design decisions.