PACELC and beyond CAP.

CAP has a blind spot, and it's a big one: the theorem only makes a statement about what happens during an active network partition — a relatively rare event. It says absolutely nothing about the overwhelming majority of the time when your network is healthy but simply slow. PACELC — coined by Daniel Abadi in 2010 — fixes exactly this gap: if there's a Partition, trade off Availability and Consistency (that's the "PAC," and it's just CAP); Else (network is fine), trade off Latency and Consistency (the "ELC," and this is the genuinely new part). This closes out Phase 1 by giving you the complete, honest picture of the consistency/performance trade-off space — the one every system in this series' remaining ten phases sits somewhere inside.

The gap CAP leaves open

Reread article 1.3's proof sketch carefully: it required an active partition to force the C-vs-A choice. What does CAP say about a healthy, fully-connected network where every message eventually arrives, just... slowly? Nothing. Literally nothing — the theorem's precondition (a partition, meaning some messages never arrive or are delayed arbitrarily) simply doesn't apply, so CAP is silent on this case entirely.

And this "healthy but slow" case isn't a minor footnote — it's the normal operating condition of almost every real distributed system, almost all the time. Partitions, while they do happen (article 1.1's GitHub and DynamoDB incidents), are measured in minutes-per-year for a well-run system. Latency — the time it takes a message to cross a datacenter, a continent, or an ocean — is present on every single request, all day, every day, whether or not anything is broken. A system design that only reasons about the rare partition case while ignoring the constant latency case is optimizing for the wrong 99.99% of operating time.

PACELC, formally

The full statement: if there is a Partition (P), how does the system trade off Availability and Consistency (A and C)? Else (E), when the system is running normally with no partition, how does it trade off Latency and Consistency (L and C)?

Read it as two nested questions, only the second of which is new:

• PA/EL — during a partition, favor availability; else (normally), favor latency over consistency. Willing to accept some staleness both during partitions and during ordinary fast-path operation, in exchange for speed and uptime in both cases. Cassandra (in its default/eventual-consistency configuration) and DynamoDB are classic PA/EL systems.
• PA/EC — during a partition, favor availability; else, favor consistency even at some latency cost. A less common combination in practice — most systems that accept staleness during a crisis (partition) also accept some for normal-path speed, since the engineering effort to be strict only when things are calm is a fairly narrow niche.
• PC/EL — during a partition, favor consistency (refuse rather than risk a wrong answer); else, favor latency, accepting some staleness on the normal fast path. Also a less common real-world combination for similar reasons.
• PC/EC — during a partition, favor consistency; else, also favor consistency over latency, always paying the coordination cost. Spanner (Phase 9.1) and most consensus-backed systems (etcd, ZooKeeper, CockroachDB in its default strong-consistency mode) are PC/EC — the "always be correct, pay for it in latency and occasional unavailability" corner.

Why strong consistency costs latency at all

Worth making the mechanism concrete rather than taking it as an assertion. Achieving CAP's linearizability (article 1.3) during normal operation requires coordination before a write (or often a read) can be considered safe — at minimum, hearing back from a quorum of replicas (the majority mechanism from article 1.2). That round-trip has a floor set by physics: light in fiber travels at roughly two-thirds the speed of light in vacuum, so a round trip between, say, Virginia and Singapore is bounded below by tens of milliseconds no matter how good your engineering is — no software optimization removes that floor, because it isn't a software problem.

A system willing to skip that coordination (serve a read from the nearest local replica without confirming it's the latest write, or acknowledge a write before hearing back from a remote quorum member) can respond in the time it takes to reach the nearest replica — often single-digit milliseconds — instead of the time it takes to reach the furthest required quorum member. That gap, multiplied across every request in a high-throughput system, is the entire "EL vs EC" trade-off in concrete terms. It's not an abstract design preference; it's a direct, measurable latency number you can benchmark.

A worked example: why Spanner is expensive on purpose

Google's Spanner (full treatment in article 9.1) is the sharpest illustration of the EC end of the spectrum being a deliberate, heavily-engineered choice rather than an oversight. Spanner wants external consistency (an even stronger guarantee than plain linearizability, ordering transactions consistently with real-world time across the whole globe) on every transaction, all the time — squarely PC/EC. To make that affordable, Google built TrueTime: a custom hardware+software time infrastructure (atomic clocks and GPS receivers in every datacenter, with an API that returns not a single timestamp but a bounded uncertainty interval) specifically so that the "wait for coordination" cost of strong consistency could be minimized and, crucially, bounded and predictable rather than a random unbounded worst case. This is a multi-year infrastructure investment made specifically to push the EC side of PACELC's latency cost as low as physically achievable — concrete proof that the trade-off PACELC names isn't academic; it's expensive enough in the real world that a company the size of Google built custom satellite-synchronized hardware to fight it.

Misconceptions PACELC clears up (and one it doesn't)

• "AP systems are just worse/less rigorous than CP systems." No — an AP/EL system making the PA/EL choice deliberately is solving a different problem (minimize latency and maximize uptime, accept bounded staleness) than a PC/EC system (never wrong, pay for it). Neither is objectively better; article 1.3's shopping-cart-vs-ledger examples show why the "right" answer is about what the data represents, not a ranking of rigor.
• "A system can be PA/EC or PC/EL cheaply." Possible but genuinely rare in practice, as the table above notes — the engineering effort to behave one way during a crisis and a structurally different way during normal operation is a narrow, specialized niche, which is part of why most real systems cluster at the PA/EL or PC/EC corners rather than spreading evenly across all four.
• What PACELC still doesn't cover: it's a useful two-axis simplification, not a complete taxonomy of consistency models. It doesn't distinguish between the many different strength levels of consistency (linearizable vs. sequential vs. causal vs. read-your-writes), and it doesn't say anything about Byzantine failures (Phase 6) at all — PACELC, like CAP, implicitly assumes crash-only failures. Treat it as a sharper lens than CAP alone, not a final word.

Closing Phase 1

Four articles in, here's the full picture assembled: 1.1 established that distributed systems fail in specific, nameable ways (unreliable networks, unsynchronized clocks, non-binary failure) rather than vaguely "being hard." 1.2 showed that replication — the natural fix for a single point of failure — creates the disagreement problem that split-brain exemplifies, and previewed majority quorums as the structural fix. 1.3 gave CAP its precise, formal treatment and cleared up the "pick two" oversimplification. This article closed the loop by naming the trade-off CAP leaves out entirely — the constant, every-request latency-vs-consistency choice that governs a system's felt performance far more than its rare-partition behavior does.

Phase 2 (Time and Failure) picks up immediately where this leaves off, by making precise exactly what "the network is slow" and "a node might have failed" actually mean, mechanically — physical and logical clocks, failure detectors, and the FLP impossibility theorem that explains, formally, why no algorithm can guarantee both correctness and termination in a fully asynchronous network with even one possible failure. That result is the deepest "why" behind every timeout, every leader-election heuristic, and every design compromise you'll see in the classical algorithms starting in Phase 5.

FAQ

Takeaways

• CAP only makes a statement about behavior during an active partition — a rare event — and says nothing about the vastly more common case of a healthy but slow network.
• PACELC (Abadi, 2010) extends CAP with a second, "Else" branch: when there's no partition, systems still trade off Latency vs. Consistency on every single request.
• Four classes exist — PA/EL, PA/EC, PC/EL, PC/EC — with real systems clustering heavily at PA/EL (Cassandra, DynamoDB) and PC/EC (Spanner, etcd, ZooKeeper); the mixed classes are rare in practice.
• The latency cost of strong consistency is a physical, not just architectural, floor — it's bounded below by the speed of light over the distance a coordination round-trip must travel.
• Spanner's TrueTime is concrete proof this trade-off is expensive enough in the real world to justify custom atomic-clock hardware built specifically to minimize it.
• Neither corner of PACELC is objectively "better" — the right choice depends on what a specific piece of data represents, exactly as article 1.3 argued for CAP alone.
• Phase 1 is now complete: you have the full vocabulary (failure modes, replication, CAP, PACELC) that every algorithm from Phase 4 onward is a specific, motivated answer to. Phase 2 makes "the network is slow" and "a node might be dead" mechanically precise.

References & further reading

• Abadi — Consistency Tradeoffs in Modern Distributed Database System Design (IEEE Computer, 2012) — the primary PACELC reference, in full.
• Abadi — Problems with CAP, and Yahoo's Little Known NoSQL System (2010) — the original blog post that introduced the PACELC framing.
• Google Cloud — TrueTime and External Consistency — how Spanner engineers around PACELC's EC latency cost; full treatment in article 9.1.
• cvam.sight — Consensus 1.3: CAP Theorem, Properly — the formal C/A/P definitions this article extends.
• cvam.sight — Consensus Algorithms series hub — Phase 2 (Time and Failure) picks up next.