PACELC Theorem

Definition: An extension of the CAP theorem stating that if there is a Partition (P), a system must trade off Availability (A) against Consistency (C); Else (E), during normal operation, it must trade off Latency (L) against Consistency (C).

How It Works

CAP only describes behavior during a network partition, which is rare. PACELC adds the “Else” branch: what does the system trade away during the vast majority of time when there is no partition at all?
The partition branch (PAC) is exactly CAP’s trade-off: when a partition happens, choose A (keep serving, risk staleness) or C (refuse to serve on the affected side, guarantee correctness).
The normal-operation branch (ELC) is new: even with a perfectly healthy network, achieving strong consistency requires coordination (waiting for acknowledgments from other replicas, or a quorum, or a consensus round), and that coordination costs latency. A system can choose low latency (accept a possibly-stale local answer) or strong consistency (pay the coordination cost on every operation).
PA/EL systems (e.g., Cassandra, DynamoDB default settings, Riak): available during a partition, and low-latency (weaker consistency) during normal operation. These systems are architected for speed and uptime as the default posture, with consistency as a tunable exception.
PC/EC systems (e.g., traditional single-leader relational databases with synchronous replication, Google Spanner): consistent during a partition (minority side refuses requests) and consistent during normal operation too, accepting the latency cost of coordination as the default posture.
A system can also mix branches, for example PA/EC: available during a partition but paying for consistency during normal operation, though this combination is less common because it takes on both the reconciliation complexity of AP and the latency cost of EC.
The “Else” (E) branch is arguably the more practically important one for most applications, because partitions might happen for minutes a year, while the L versus C trade-off is paid on every single request, every day.
Spanner’s approach to EC is instructive: rather than accepting unbounded coordination latency, it uses synchronized clocks (TrueTime) with a bounded uncertainty window, converting “wait for a quorum round trip” into “wait out a small, bounded clock-uncertainty interval,” which lowers but doesn’t eliminate the latency cost of consistency.
The PACELC matrix has four theoretical quadrants (PA/EL, PA/EC, PC/EL, PC/EC), but PC/EL is rarely seen in practice: a system that refuses availability during a partition to guarantee consistency, yet doesn’t pay any coordination cost when healthy, is an unusual combination since the same replication machinery that enforces C during a partition typically also imposes a latency cost during normal operation.

Worked Example: Quantifying the “Else” Cost

Consider a 3-region deployment (US, EU, Asia) with 50ms one-way network latency between the farthest regions. An EL read served from the local region completes in roughly 1-2ms, dominated by local disk/memory access. An EC read requiring a majority quorum across regions must wait for the slowest region in that majority to respond, at minimum one round trip to the farthest required replica, around 100ms round-trip in the worst case, before the read can be considered safe to return. That’s roughly a 50-100x latency difference paid on every single request, every day, regardless of whether a partition ever occurs, which is the concrete number PACELC is naming as the “Else” cost that CAP alone never surfaces.

Trade-offs

Choosing EL (low latency, weaker consistency during normal operation) means every read can be served by the nearest replica without a coordination round trip, but that read might return data that’s a few milliseconds, or longer under lag, out of date.
Choosing EC (strong consistency during normal operation) means every operation that needs a consistent view pays a coordination cost, quorum round trips, consensus rounds, or synchronized-clock waits, even when nothing is failing.
The P-branch choice and the E-branch choice don’t have to match philosophically, but in practice they usually do, because the same replication and quorum machinery that makes a system CP during a partition (waiting for majority agreement) is the same machinery that makes it EC during normal operation (that agreement isn’t free even when the network is healthy).
PACELC makes explicit that “eventual consistency” isn’t just a partition-tolerance feature, it’s usually adopted because it removes the everyday latency tax of EC, which matters far more to user-facing performance than partition-time behavior.

Why It Matters

It provides a complete trade-off model explaining database performance during normal, healthy operation, not just during the rare network split that CAP alone addresses.
It reframes “why is this database eventually consistent” from a partition-tolerance question into a latency question, which is usually the actual reason a team picked that database.
It gives a vocabulary for comparing databases on equal footing: two AP systems can still differ meaningfully in their EL/EC posture, which CAP alone can’t express.

Common Pitfalls

Expecting zero-latency reads while also enforcing strict, global, linearizable consistency. PACELC’s whole point is that this combination isn’t achievable, coordination has a floor cost set by network round-trip time.
Evaluating a database purely on its CAP classification and ignoring its PACELC classification, which misses the trade-off that actually affects users on a daily basis.
Assuming EL and EC are fixed properties of a database engine rather than often being a per-query, tunable setting (read/write consistency levels in Cassandra, DynamoDB’s eventually-consistent vs strongly-consistent reads).
Believing “the network is healthy right now” means consistency is free. Even with a healthy network, achieving linearizability requires waiting for coordination; the cost doesn’t disappear, it’s just not caused by a failure.
Treating PA/EL and PC/EC as the only two valid combinations. Real systems, and even individual queries within the same system, can land anywhere on this matrix depending on configuration.
Blaming “the network” for latency that’s actually the E-branch coordination cost. Slow requests during normal operation are frequently a consistency choice working as designed, not an infrastructure problem to be tuned away.
Comparing two databases’ benchmark numbers without checking they were tested at the same consistency level; an EL benchmark and an EC benchmark of the same underlying system aren’t measuring the same thing.

Comparison

	CAP Theorem	PACELC Theorem
Scope	Only during a network partition	Partition AND normal operation
Trade-off named	Consistency vs Availability	Consistency vs Availability (P), Consistency vs Latency (E)
Explains everyday latency cost	No	Yes
Best for	Reasoning about failure-mode design	Reasoning about the day-to-day cost of a consistency choice

System	Partition (P) posture	Normal operation (E) posture	Classification
DynamoDB (default)	Available, may be stale	Low latency, may be stale	PA/EL
Cassandra (`ONE` consistency)	Available, may be stale	Low latency, may be stale	PA/EL
Google Spanner	Consistent, may reject requests	Consistent, bounded latency cost via TrueTime	PC/EC
MongoDB (majority read/write concern)	Consistent, minority side blocks	Consistent, pays quorum round-trip cost	PC/EC
Riak (default `N=3, R=1, W=1`)	Available, may be stale	Low latency, may be stale	PA/EL
PostgreSQL (single primary, synchronous replica)	Consistent, blocks without a healthy replica	Consistent, pays sync-replica round trip	PC/EC

Real-World Scenario

A social media feed service uses a PA/EL database: under normal conditions, a “like” count read from the nearest replica returns in a few milliseconds, occasionally a couple of seconds stale, which nobody notices. During a rare regional network partition, the service keeps serving reads and writes from whichever side users are connected to, occasionally showing slightly different like counts to users on opposite sides of the partition until it heals. Compare that to the same company’s ad billing ledger, built on a PC/EC store: every write pays a quorum round trip even on a perfectly healthy day, because a billing discrepancy is far more costly than the extra tens of milliseconds of latency.

Debugging Walkthrough: Diagnosing an “Else” Latency Regression

A team migrates a feature’s read path from a PA/EL cache-backed store to a PC/EC store for correctness reasons (avoiding stale reads on a pricing field). A week later, p99 latency on that endpoint has doubled, with no change in traffic volume.
First check: is this a partition-time symptom or a normal-operation one? The infrastructure dashboard shows zero partition or quorum-loss events during the regression window, ruling out the “P” branch entirely, this is squarely an “E” (else) branch cost.
Tracing a single slow request shows the added latency sits entirely in the database call, specifically in the time between the query being issued and the leader receiving acknowledgment from a majority of replicas, the quorum round trip the new PC/EC store pays on every write and every linearizable read that the old PA/EL cache never paid.
Comparing replica placement: the majority-quorum replicas span two regions with a 40ms network round trip between them, while the old cache’s reads were always served from the local region with sub-millisecond latency. The consistency upgrade didn’t just add “some” latency, it added a fixed, unavoidable cross-region round trip to the critical path.
Resolution options are then genuinely PACELC trade-offs, not bugs to “fix”: either accept the latency as the cost of correctness, move the quorum replicas into the same region (reducing the durability guarantee against a regional failure), or scope strong consistency to only the specific fields that need it (the price) while serving the rest of the response from a faster, eventually-consistent path.
The team chooses the last option: a hybrid read that fetches the price with a linearizable read and everything else from cache, cutting p99 back down while keeping the one field that mattered correct. The postmortem explicitly notes this as a PACELC classification problem, applying EC to an entire response when only one field needed it.

FAQ

Is PACELC a replacement for CAP, or an addition to it? An addition. PACELC explicitly includes CAP’s partition-time trade-off as its “P” branch and extends it with the “E” (else) branch for normal operation.

Can a system be PA/EC? Yes, though it’s uncommon: available during a partition (accepting divergence) but paying full coordination cost for consistency when the network is healthy. It takes on both AP’s reconciliation complexity and EC’s latency cost without getting the simplicity benefit of either pure strategy.

Does choosing EL mean a system has no consistency guarantees at all? No, EL systems usually still offer eventual consistency and often tunable stronger-consistency reads on request, at the cost of the latency PACELC describes.

Do all AP systems automatically get low latency (EL)? Not automatically, but in practice yes, since the same design choice that avoids blocking on quorum during a partition (serve from the local/nearest replica) is what avoids the coordination round trip during normal operation too. A system could theoretically be AP but still choose to coordinate for latency reasons, it would just be an unusual, self-defeating design.

How would you explain PACELC to someone who only knows CAP? CAP tells you what a database does during the rare moment the network breaks. PACELC adds the other 99.99% of the time: even when nothing is broken, being consistent still costs you speed, and that cost is what most eventually-consistent systems are actually built to avoid.

Why does Spanner count as EC if it’s fast in practice? Spanner still pays a real latency cost for consistency, bounded by TrueTime’s clock uncertainty window, it’s just engineered to make that cost small and predictable rather than eliminating it.

History

PACELC was introduced by Daniel Abadi in a 2010 paper and blog post, “Consistency Tradeoffs in Modern Distributed Database System Design,” directly responding to what he saw as CAP’s incomplete framing of the consistency trade-off.
Abadi’s core observation was that CAP’s “2 of 3” framing implies partitions are the central design driver, when in practice systems spend nearly all their time in a non-partitioned state, where the real, constant trade-off is latency versus consistency.
The theorem has since become a standard part of distributed systems curricula and system design interviews specifically because it explains the “why” behind eventually-consistent systems’ design in a way CAP alone doesn’t.

Common Interview Questions

What gap in CAP does PACELC address? CAP is silent on system behavior when there’s no partition; PACELC adds the latency-versus-consistency trade-off that applies during normal, healthy operation.
Why can’t a system achieve both low latency and strong consistency simultaneously? Strong consistency requires coordination between nodes (a quorum round trip, a consensus step), and coordination has an inherent network round-trip cost that a purely local read or write doesn’t pay.
How would you classify a database that offers tunable consistency per query? By its default and its available range, e.g., DynamoDB defaults to PA/EL but can be configured per-request for strongly-consistent (higher latency) reads.
Why is Spanner PC/EC despite being marketed as fast? Because it still pays a real, if minimized, latency cost for consistency via TrueTime’s bounded clock uncertainty; “fast” here means “fast for a consistent system,” not “as fast as an eventually-consistent one.”

Example

DynamoDB, by default, sacrifices strict consistency during normal operations to achieve single-digit-millisecond latency (PA/EL), but offers strongly-consistent reads as an opt-in, higher-latency alternative on a per-request basis. Google Spanner pays for global consistency with added, bounded latency via synchronized clocks, making it PC/EC by design.

Design Checklist

For this specific data path, is the everyday latency cost of strong consistency actually justified, or is the team paying for EC without a real business reason?
Does the database expose a tunable per-query consistency level, so different features on the same system can pick their own point on the L/C trade-off?
Has the partition-time (P) behavior been tested explicitly, separately from the normal-operation (E) behavior, since a system can be well-tuned for one and untested for the other?

Referenced by

Dig deeper

Spot an error in this note?