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
Common Mistakes and Trade-offs
A pervasive mistake developers make when evaluating CAP is assuming that 'strong' consistency always equates to better performance. The CAP theorem describes a fundamental constraint – you can only truly optimize for two of the three properties simultaneously. Many teams, particularly those new to distributed systems, attempt to aggressively pursue strong consistency across their entire application, leading to significant bottlenecks in latency and throughput. This isn't about technical limitations; it's often driven by a desire to avoid perceived data corruption or inconsistencies, which are manageable with proper error handling and monitoring. The reality is that some level of eventual consistency can dramatically improve the responsiveness of your system without introducing unacceptable levels of risk – provided you architect around those risks effectively.
At scale, a significant trade-off emerges regarding network partitions that isn't immediately apparent in small deployments. While CAP focuses on availability and partition tolerance, the constant need to synchronize data across geographically distributed nodes introduces increasingly complex latency problems. Even with optimized protocols like Paxos or Raft, the cumulative effect of network hiccups – even brief ones – can lead to divergent states between replicas, requiring sophisticated conflict resolution strategies that consume substantial operational overhead. This isn't simply about 'CAP failing'; it's about the increasing cost of managing a system where data synchronization is a continuous, low-level concern driving infrastructure and development effort.
The misconception that PACELC is 'always better' than CAP stems from a misunderstanding of its intended scope. PACELC isn't a replacement for CAP; it's an additional constraint to consider alongside it. PACELC prioritizes Personalization, Access Latency, Consistency, Eventual Consistency, and Location – but it fundamentally assumes you need all of these things simultaneously in the same system. CAP is relevant when you're dealing with a fundamental conflict between availability and strong consistency. Applying PACELC blindly to every scenario will invariably lead to suboptimal choices and increased complexity. It's a useful lens for evaluating requirements, not a magic bullet.
Migrating from a CAP-based architecture to a PACELC one (or vice versa) isn't a simple switch; it requires a complete reevaluation of your data model and operational strategy. Attempting a direct conversion often results in introducing inconsistencies or performance bottlenecks. Furthermore, truly leveraging PACELC effectively necessitates sophisticated techniques like geo-partitioning, content delivery networks, and predictive analytics to manage personalization at scale – investments that weren't necessarily part of the original CAP design. A more pragmatic approach is to analyze your needs through a combined lens, recognizing that many systems benefit from incorporating elements of both strategies, perhaps using CAP for core transaction data while employing PACELC principles for user-facing content delivery.
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.