PACELC extends the CAP theorem with a clause for when the network is NOT partitioned. What does the 'ELC' part of PACELC add, and how does it change a system's design compared to only thinking in CAP terms?

## The gap CAP leaves open CAP theorem only tells you what happens in the exceptional case: when the network is partitioned. It says nothing about system behavior during the vast majority of the time a distributed system is actually running, which is the normal case where all nodes can reach each other. Daniel Abadi pointed out in 2010 that this gap matters, because even with a healthy network, a distributed system still has to make a consistency-versus-performance trade-off on every operation, and that trade-off looks nothing like the partition-time choice CAP describes. He proposed **PACELC** to name both trade-offs in one formula: 1. If there is a **Partition (P)**, choose between Availability and Consistency (A or C) — exactly CAP. 2. **Else (E)**, when the system is running normally with no partition, choose between Latency and Consistency (L or C). ## Why the else clause exists The mechanism behind the 'else' clause is straightforward once you look at what strong consistency actually requires operationally. To guarantee a read always returns the most recent write, a system generally must involve more than one node in every operation: - a **write** has to be acknowledged by a quorum of replicas, or all of them, before it's considered committed; - a **read** may need to check with a quorum or the current leader to be sure it isn't returning stale data. Every extra round trip costs real time — network latency within a data center might be sub-millisecond, but between regions it can be tens to hundreds of milliseconds. So a system that insists on strong consistency pays a latency tax on every request, partition or not. A system willing to relax consistency can skip those round trips — serve a read from the nearest local replica, acknowledge a write as soon as one node has it — and respond far faster, at the cost that a read might not reflect the very latest write yet. ## What the formula adds to CAP This gap existed in CAP because CAP was framed as a theorem about an exceptional failure condition, but engineers designing globally distributed systems needed to justify decisions that had nothing to do with rare partitions — decisions like 'should this read go to the local replica or the leader replica three regions away' made on every request under totally normal conditions. PACELC gives that decision a name and slots it next to the CAP decision so the two don't get conflated. A system can, for instance, be **CP** under CAP — sacrificing availability during a partition to stay consistent — while also being **EL** under PACELC — favoring low latency over the strongest consistency in normal operation — a combination CAP alone can't express, because CAP is silent about the non-partitioned case entirely. ## The cost on each side The trade-off has a concrete cost on each side. | The everyday choice | What it costs, and the data it suits | |---|---| | **Favoring Consistency** in the 'else' branch | Means every operation pays the coordination latency described above — acceptable for data where correctness matters more than milliseconds, like a bank balance or an inventory count that must never oversell. | | **Favoring Latency** | Means operations return fast using local or cached state, at the cost that different clients can briefly see different answers to the same query even with a perfectly healthy network — acceptable for data like a like-count or a recommendation where a few seconds of staleness is invisible but a slow page load isn't. | ## The failure mode it produces The failure mode this trade-off produces in production is subtler than a partition-triggered outage: teams that don't think in PACELC terms often discover, well after launch, that their system is slower than expected under normal conditions because every read is doing a full quorum round-trip across regions for data that never needed strong consistency in the first place — the 'else' cost was being paid on every request, silently, with no partition in sight to explain it. The fix is usually to identify which operations actually require the latest-write guarantee and downgrade the rest to a faster, locally-served read path. ## The trade-off made explicit in an API A concrete real-world example: DynamoDB offers a per-read choice between 'eventually consistent reads' and 'strongly consistent reads.' - The **eventually consistent** option is roughly twice as fast and cheaper, served from whichever replica is closest, because it skips the coordination step. - The **strongly consistent** option routes the read through a path that confirms it reflects the latest acknowledged write, at higher latency and cost. That single API parameter is PACELC's ELC trade-off made explicit and left to the application developer to choose per call, rather than baked into the system as a single global policy — exactly the kind of everyday decision CAP alone gives no vocabulary for.