Distributed systems theory comparison
CAP theorem vs PACELC theorem
CAP theorem is the famous one everyone quotes in interviews — "pick two of Consistency, Availability, Partition tolerance." PACELC is the lesser-known extension that points out CAP only describes what happens during a rare partition, and misses the trade-off every distributed system makes on every single request, partition or not.
TL;DR
- CAP theorem says: when a network partition happens, you must choose between Consistency and Availability — you cannot have both.
- PACELC theorem extends this: even when there is no partition ("Else"), you still choose between Latency and Consistency on every request.
- Together they fully classify a system's behaviour: e.g. "PA/EL" (available during partitions, low-latency otherwise) or "PC/EC" (consistent both during partitions and normally).
Side-by-side comparison
| Aspect | CAP theorem | PACELC theorem |
|---|---|---|
| Published | 2000 (Eric Brewer, conjecture); proven 2002 | 2010 (Daniel Abadi, as an extension of CAP) |
| Scope | Behaviour only during a network partition | Behaviour during a partition AND during normal operation |
| Trade-off during partition | Consistency vs Availability (the "P" is a given, not optional) | Same as CAP — labelled "PA" or "PC" |
| Trade-off with no partition | Not addressed | Latency vs Consistency — labelled "EL" or "EC" |
| Classification format | CP or AP (2 letters) | PA/EL, PC/EC, PA/EC, PC/EL (4 letters) |
| Common criticism | "Pick 2 of 3" oversimplifies — partition tolerance isn't optional at scale | More accurate, but less catchy and less widely taught |
| Example: DynamoDB | AP — favours availability during partitions | PA/EL — also favours low latency during normal operation |
| Example: strongly consistent quorum DB | CP — favours consistency during partitions | PC/EC — also pays a consistency-driven latency cost normally |
Reasoning through an example, side-by-side
CAP-only analysis
Scenario: network partition splits
the cluster into two halves.
Question CAP answers:
"Does the minority-side node keep
accepting writes (Available), or
does it refuse to serve until it
can confirm consistency (Consistent)?"
Answer for this system: CP
-> refuses writes on the minority side
until the partition heals.
// CAP says NOTHING about what
// happens on a normal Tuesday
// with no partition at all.PACELC analysis (adds the "Else" case)
Scenario 1 (Partition): same as CAP -> CP
Scenario 2 (Else -- no partition,
normal healthy cluster):
"Does every read wait for a quorum
of nodes to confirm the latest
value (Consistent, but slower), or
does it return from the nearest
replica immediately (fast, but
possibly slightly stale)?"
Answer for this system: EC
-> reads always go through a quorum,
even with zero partitions, because
the system prioritises consistency
over latency at all times.
Full classification: PC/ECWhen CAP theorem is the right lens
- Explaining failover and outage behaviour. "What happens to writes if this data centre gets cut off from the others" is a pure CAP question — CP vs AP.
- Quick, high-level architecture conversations. CAP's two-letter classification is fast to communicate and widely understood, even if it's an incomplete picture.
- Choosing a database primarily for partition resilience. If your main concern is "what happens during a regional outage," CAP alone answers the headline question.
- Teaching the basic vocabulary of distributed trade-offs. CAP is the standard entry point before introducing PACELC's added nuance.
When you need PACELC's fuller picture
- Evaluating day-to-day read/write latency, not just outage behaviour. Most requests happen when there's no partition — PACELC tells you what to expect on an ordinary day.
- Comparing two "AP" or two "CP" systems that behave very differently in practice. Two CP systems can have wildly different normal-operation latency depending on whether they're also EC or EL.
- System-design interviews at a senior level. Bringing up PACELC after stating a CAP classification signals a deeper, more complete understanding of the trade-off space.
- Justifying a database choice with real numbers. "This system is PC/EC, so expect quorum-read latency on every request, not just during rare partitions" is a much more actionable statement for capacity planning.
English phrases engineers use
CAP conversations
- "During a partition, are we CP or AP?"
- "We sacrifice availability on the minority side to stay consistent."
- "Partition tolerance isn't optional once you're distributed."
- "That's the classic CAP trade-off in a system-design interview."
PACELC conversations
- "Even with no partition, we're paying a consistency tax on every read."
- "This system is PA/EL — fast normally, available during partitions."
- "Don't just say CP — what's it doing on the 'Else' branch?"
- "We chose EL over EC to keep p99 latency low."
Quick decision tree
- Just explaining outage/failover behaviour → CAP theorem is enough
- Justifying day-to-day latency expectations → Use PACELC's "Else" classification
- Comparing two databases with the same CAP label → Differentiate them with PACELC (EL vs EC)
- Senior system-design interview → State both CAP and PACELC classification
- Need lowest possible latency, can tolerate brief staleness → Target an EL system (and usually PA too)
- Need every read to reflect the latest write, always → Target an EC system (usually PC too), accept the latency cost
Frequently asked questions
What does PACELC add that CAP does not cover?
CAP only describes the trade-off during a network partition: choose Consistency or Availability. PACELC extends this by pointing out that even when there is no partition at all (the "Else" branch), a system still has to choose between Latency and Consistency for every single request — a strongly consistent read that has to check with a remote replica or leader is slower than one that can be answered locally. PACELC says every distributed database makes this trade-off constantly, not just during rare partition events.
Is CAP theorem actually about picking 2 of 3?
The "pick two of three" framing is a popular simplification that is technically misleading. In practice, network partitions are unavoidable at scale (you cannot choose not to have them), so the real choice CAP describes is: when a partition happens, do you sacrifice Consistency or Availability? You don't get to trade away Partition tolerance in any system that spans more than one node over an unreliable network.
How would I classify a real database using PACELC?
You need two letters for the partition case and two for the normal case. For example, DynamoDB is PA/EL — during a Partition it favours Availability, and Else (no partition) it favours Latency over strict consistency. MongoDB (with default settings) and traditional single-primary relational databases with synchronous replicas are closer to PC/EC — Consistency in both cases, at the cost of availability or latency respectively.
Does choosing "CP" in CAP guarantee low latency?
No — this is exactly the gap PACELC fills. A CP system prioritises consistency during a partition, but PACELC asks a separate question about normal operation: does that same system also pay a consistency-driven latency cost even when there's no partition? Many CP systems (e.g. ones requiring a quorum read from multiple nodes) are also EC systems, paying a latency tax on every read to stay consistent, partition or not.
Why do interviewers ask about both CAP and PACELC?
CAP alone gives an incomplete picture of a system's real-world behaviour, since partitions are (hopefully) rare while the latency/consistency trade-off happens on literally every request. An interviewer asking "is this system CP or AP" and then following up with "and what about during normal operation" is testing whether you understand that trade-offs exist beyond failure scenarios — a common signal of deeper distributed-systems understanding.
Can a system be AP under CAP but EC under PACELC?
Yes, and this combination is common. A system might choose availability over consistency during a rare partition (AP) but, during normal healthy operation, still route all reads and writes through a quorum or a single leader to maximise consistency (EC) — paying the latency cost since partitions are the exception, not the rule the system optimises for day-to-day.
Where does eventual consistency fit into this framework?
Eventual consistency is typically what an AP/EL system provides: available under partitions, and low-latency during normal operation, at the cost of replicas that may briefly disagree. It's the default trade-off for systems like DynamoDB or Cassandra (in their typical configurations) that prioritise responsiveness and uptime over every read reflecting the very latest write immediately.