PACELC Theorem: The Tradeoff CAP Doesn't Cover
Foundations Series
| # | Post | What it covers |
|---|---|---|
| 00 | Intro | What the Foundations pillar covers and why it matters |
| 01 | Availability | Uptime, the nines, and why 99% isn't good enough |
| 02 | Reliability | Correctness over time — when uptime isn't enough |
| 03 | Latency vs Throughput vs Bandwidth | The three numbers that define system performance |
| 04 | ACID vs BASE | Two philosophies for handling data under pressure |
| 05 | CAP Theorem | The impossibility result every distributed system runs into |
| 06 | PACELC Theorem ← you are here | What CAP doesn't tell you about latency |
| 07 | Consistency Models | The spectrum from "always correct" to "eventually correct" |
| 08 | Single Point of Failure | Why one weak link breaks the whole chain |
| 09 | High Availability vs Fault Tolerance | Similar goals, very different strategies |
| 10 | Wrap-up | How all nine concepts connect |
PACELC Theorem: The Tradeoff CAP Doesn't Cover
The problem
Your team just finished a long debate about your new distributed database. You've read the CAP Theorem post. You've decided: you're building an AP system — available during partitions, eventually consistent. The architects are satisfied, the decision is documented, and everyone moves on.
Six months later, your performance team raises a flag. Reads from your European nodes are noticeably slower than expected — even during periods of perfectly healthy network operation, with zero partitions. The issue traces back to your consistency configuration: every read is waiting for acknowledgement from a quorum of nodes spread across three regions before returning a result.
Nobody chose this deliberately. It crept in as a default. And it's costing 80ms per read, globally, every day — not just during the partitions CAP is concerned with.
CAP told you what to sacrifice when the network breaks. It said nothing about the price you pay when it doesn't.
The core idea
PACELC Theorem, proposed by Daniel Abadi in 2010, extends CAP by acknowledging a tradeoff that CAP ignores entirely: even during normal operation — no partition, healthy network, all nodes communicating — distributed systems must still choose between latency and consistency.
The theorem states:
If there is a Partition, the system must choose between Availability and Consistency (the CAP choice). Else, when the system is running normally, it must choose between Latency and Consistency.
Written as an acronym: PAC / ELC — or PACELC.
It's not a replacement for CAP. It's the second half of the sentence CAP left unfinished.
The analogy: two branches, now with a working phone
In the CAP post, we used two bank branches whose phone line went down. The phone line going down was the partition, and the branches had to choose between consistency and availability.
Now the phone line is working perfectly. A customer at the Sydney branch wants to check their balance. The teller can call Singapore to confirm the current balance before answering — accurate, but the customer waits on hold while the call connects, Singapore looks up the record, and the teller relays the answer.
Or the teller can read from the local ledger and answer immediately — faster, but if Singapore processed a transaction in the last few seconds that hasn't been synced yet, the balance might be slightly stale.
No partition. Network perfectly healthy. Still a choice between latency and consistency — and it happens on every single transaction, not just during failures.
This is the ELC half of PACELC: Else (no partition), choose between Latency and Consistency.
How it works
The full PACELC classification
Every distributed system can be classified by how it handles both halves of the theorem:
During partition (PAC): choose A or C
During normal operation (ELC): choose L or C
This gives four possible classifications:
| Classification | During Partition | During Normal Operation | Examples |
|---|---|---|---|
| PA / EL | Availability | Low Latency | Cassandra, DynamoDB (default), CouchDB |
| PC / EC | Consistency | Consistency | HBase, VoltDB, Zookeeper |
| PA / EC | Availability | Consistency | MongoDB (in certain configs) |
| PC / EL | Consistency | Low Latency | PNUTS (Yahoo) |
The most common real-world systems land in PA/EL or PC/EC — the two corners that are internally coherent. A system that prioritises availability during partitions tends to also prioritise low latency during normal operation, because both reflect the same underlying philosophy: respond fast, reconcile later. A system that prioritises consistency during partitions tends to maintain that standard all the time.
Why the ELC tradeoff exists
When a distributed database receives a read request, it has options:
Serve from the local node immediately. Zero coordination overhead — lowest possible latency. Risk: the local node may not have received recent writes from other nodes yet. The read might be stale by milliseconds, seconds, or in pathological cases, longer.
Wait for a quorum of nodes to agree. A majority of nodes confirm they hold the same value before responding. Guaranteed to be current. Cost: the time it takes to send requests to multiple nodes, wait for responses, and agree — all of which adds latency that scales with geographic distance and node count.
Wait for all nodes to confirm. The strongest possible consistency. The highest possible latency. Used almost nowhere in practice.
For a cluster with nodes in Sydney, London, and Virginia, "wait for quorum" adds the round-trip time of the slowest participating node to every read. If Virginia is 200ms away from Sydney, quorum reads from Sydney take at least 200ms — not because the Sydney node is slow, but because consistency requires waiting for the distant node to weigh in.
PACELC in the databases you already use
Cassandra is PA/EL. During a partition it stays available. During normal operation it serves reads from the nearest replica immediately, without waiting for global agreement. You can tune this — Cassandra's consistency levels let you request quorum reads — but the default optimises for latency. The tradeoff is explicit and configurable.
DynamoDB (default) is PA/EL. Reads return the most recently written value as seen by the serving node. For an additional read cost, you can request strongly consistent reads — but you're paying for that ELC shift from L to C explicitly.
HBase is PC/EC. It sacrifices availability during partitions and always enforces strong consistency, even at the cost of higher read latency. Every read goes through the same coordination path.
Google Spanner is an interesting case: it aims for PC/EC using GPS and atomic clocks to minimise the latency cost of strong consistency. It doesn't eliminate the ELC tradeoff — it shrinks it to a level most applications don't notice. Spanner is the existence proof that PC/EC doesn't have to mean "slow" — but it requires extraordinary infrastructure investment to achieve.
Why PACELC is more practically useful than CAP
Network partitions are relatively rare in well-maintained infrastructure. A major cloud provider's within-region network experiences partitions on the order of hours per year. Your CAP choice matters — but it's exercised infrequently.
The ELC tradeoff is exercised on every single read and write your system processes.
If your system handles 50,000 reads per second and each one waits an extra 50ms for consistency coordination, that coordination cost is always present — not just during the handful of partition events per year. The cumulative latency impact of the ELC choice dwarfs the impact of the PAC choice for most production systems.
PACELC forces the question teams often skip: not just "what do we do when the network breaks?" but "what do we do on a perfectly ordinary Tuesday at 2pm?"
The tradeoffs
Choosing EL (low latency) means accepting staleness windows. You need to define how stale is too stale for each data type in your system. A social media follower count being 500ms stale is acceptable. A seat reservation being 500ms stale can cause double-booking.
Choosing EC (consistency) means paying a latency tax on every operation. In geographically distributed systems, this tax is proportional to the distance between your nodes. If you need strong consistency and low latency, you either co-locate your nodes (sacrificing geographic redundancy) or invest in infrastructure like Spanner that minimises coordination overhead through specialised hardware.
Mixing models is usually the right answer. Most real systems have different consistency requirements for different data. User session data can be eventually consistent. Account balances cannot. The practical approach is to classify your data by consistency requirement and configure each data store accordingly — not find one setting that works for everything.
PACELC and CAP together
Read as a pair, CAP and PACELC give you a complete framework for reasoning about distributed system tradeoffs:
CAP: What breaks during a partition, and which property do you protect?
PACELC: What do you optimise for every other minute of every other day?
A system's full character isn't captured by its CAP classification alone. Two AP systems can behave very differently in normal operation — one serving stale reads instantly, one coordinating for consistency with added latency. PACELC is what distinguishes them.
The one thing to remember
Network partitions are rare. The ELC tradeoff is constant. CAP describes a failure scenario you'll encounter a handful of times a year. PACELC describes a choice your system makes on every read and every write, forever. Know your system's ELC position as well as you know its CAP position — because in practice, latency vs consistency is the tradeoff your users feel every day.
← Previous: CAP Theorem — the impossibility result during network partitions
→ Next: Consistency Models — CAP and PACELC both hinge on the word "consistency," but consistency isn't binary. The next post maps the full spectrum — from strong consistency to eventual consistency — and everything in between.
