PACELC Theorem
CAP only describes what happens during a partition — PACELC covers the trade-off a system faces the rest of the time.
Overview
PACELC extends CAP theorem by pointing out that CAP only describes behavior during a network partition (P) — but even when the network is perfectly healthy (Else), a distributed system still faces an unavoidable trade-off between Latency and Consistency, because keeping every replica in sync before acknowledging a write always costs time.
Why It Exists
CAP alone leaves a real gap: it says nothing about the vastly more common case where there's no partition at all — which is where a system spends the overwhelming majority of its time. PACELC exists specifically to name the trade-off that still applies during completely normal operation: if Partitioned, choose Availability or Consistency (the same choice CAP describes); Else, choose Latency or Consistency.
Real World Example
A multi-region database can either wait for a write to be confirmed by replicas in every region before acknowledging it back to the caller — higher latency, strong consistency — or acknowledge the write as soon as the local region has it, replicating to other regions asynchronously — lower latency, but replicas briefly lag behind. Critically, the database has to make this choice on every single write, partition or no partition.
The Two Branches of PACELC
P — If Partitioned: Availability or Consistency
The same choice CAP theorem describes — during an actual network partition, choose to keep answering (A) or to refuse rather than risk inconsistency (C).
E — Else (Normal Operation): Latency or Consistency
The part CAP doesn't cover. Even with a perfectly healthy network, a write can be acknowledged immediately from the local node (low latency, replicas catch up asynchronously) or only after every replica confirms it (strong consistency, higher latency). This trade-off is active essentially all the time, not just during rare partition events.
Diagram
PACELC asks a second question CAP never does: what happens when there's no partition at all?
Is the system currently partitioned?
Choose Availability
keep answering
Choose Consistency
refuse rather than risk it
Choose Latency
acknowledge locally, replicate async
Choose Consistency
wait for replica confirmation
Common Mistakes
Thinking PACELC only matters during rare partition events
Why: The 'Else' (normal operation) branch is the one that applies essentially all the time — and it's the one CAP doesn't even address. Ignoring it means missing the trade-off that actually affects users on a daily basis, not just during outages.
Fix: Evaluate a system's Else-branch behavior — latency vs. consistency during healthy operation — as seriously as its partition behavior.
Assuming a system's PACELC classification is fixed and can't be tuned
Why: Many systems (Cassandra, DynamoDB) let you choose the Latency-vs-Consistency trade-off per query via a tunable consistency-level setting, rather than being locked to one classification for every operation.
Fix: Check whether the specific engine exposes this as a tunable setting instead of assuming a textbook classification applies unconditionally to every query.
Confusing PACELC's 'Latency' trade-off with plain network speed
Why: It specifically refers to the extra latency cost of coordinating with replicas to achieve stronger consistency, not general network performance — a faster network makes both options quicker, but the relative trade-off between them remains.
Fix: Think of PACELC's L as 'coordination cost,' not 'how fast is our network.'
Interview Questions
What gap in CAP theorem does PACELC fill?
CAP only describes trade-offs during a network partition. PACELC adds that even during completely normal, non-partitioned operation, a distributed system still faces a trade-off between latency and consistency.
Explain the 'Else' branch of PACELC with an example.
During normal operation, a write can either be acknowledged as soon as it reaches one node (low latency, but other replicas are briefly behind) or only after it's confirmed by every relevant replica (strong consistency, but higher latency waiting for that confirmation). A multi-region database choosing between local-acknowledgment and cross-region-confirmation for writes is a direct example of the Else branch in action.
How would you decide where on the Latency-vs-Consistency spectrum to place a specific piece of data in your system?
By weighing the real cost of staleness against the real cost of added latency for that specific data. A user's own profile update benefits from low latency and can usually tolerate brief staleness elsewhere. A payment or inventory decrement usually can't tolerate staleness at all, and should pay the latency cost of stronger consistency. This is a per-data-type decision, the same way the CP-vs-AP choice in CAP is made per service rather than once for the whole system.
Production Best Practices
Do
✓Evaluate a system's normal-operation (Else) trade-off, not just its partition-time behavior.
✓Check whether your database exposes a tunable, per-query consistency level instead of assuming one fixed classification.
✓Make the Latency-vs-Consistency decision per data type, based on the real cost of staleness for that data.
Don't
✗Don't only design for the rare partition case and ignore the far more common Else case.
✗Don't assume a system's PACELC classification is unconditionally fixed.
✗Don't confuse the 'L' trade-off with raw network speed — it's specifically about replica-coordination cost.
Comparison
| Partition Behavior (PA/PC) | Normal-Operation Behavior (EL/EC) | |
|---|---|---|
| DynamoDB | PA — stays available | EL — favors low latency |
| Cassandra | PA (tunable) | EL (tunable per query) |
| Google Spanner | PC — favors consistency | EC — favors consistency |