PACELC & the Steady-State Tradeoff

CAP's blind spot: the other 99.99% of the time

CAP only describes behavior during a partition, which is a rare event. It says nothing about the tradeoff you pay on every single request when the network is fine. PACELC (Abadi) fills that hole. Read it as: if Partition (P), choose Availability or Consistency (A/C); Else (E), choose Latency or Consistency (L/C). The first half is just CAP. The second half, the ELC part, is the one that actually shapes your latency budget day to day.

The else-case insight: strong consistency is never free

To guarantee a linearizable read or write, a system must coordinate, and coordination is round trips:

• A linearizable write must reach a majority quorum (or a single leader that then replicates to a quorum) before acknowledging. In a 3-region deployment, that quorum round trip can add tens to over a hundred milliseconds to every write, because you wait for the second-fastest region.
• A linearizable read cannot just read the nearest replica, because that replica might be stale. It must either go to the leader (a round trip, possibly cross-region) or read from a quorum and take the newest value.

That is the ELC tax. A system that chooses EL (latency over consistency in the normal case) answers from the nearest replica immediately and risks a stale read. A system that chooses EC pays the coordination round trip on every strongly-consistent operation. A real, measurable tail-latency cost, not a philosophical one.

The major stores on the spectrum

• DynamoDB: PA/EL. Available under partition; normally favors latency, serving eventually-consistent reads from the nearest copy, with an opt-in strongly-consistent read as the per-operation EC lever.
• Cassandra: PA/EL. Available under partition, low-latency by default, with per-query tunable consistency (ONE is EL, QUORUM/ALL push toward EC).
• Spanner: PC/EC. Consistent during a partition (minority steps down), and even normally it pays for consistency: TrueTime commit-wait and Paxos quorum round trips on every commit.
• CockroachDB: PC/EC. Same posture via Raft per-range and hybrid logical clocks: strongly consistent, paying quorum latency to be so.
• PA/EC also exists (some tunable stores): available under partition but preferring consistency when healthy.

Interview nuance: the mistake that reads as junior is reasoning only about partitions. If you say "we'll use strong consistency, partitions are rare so it's cheap," you have missed that strong consistency taxes every request. The staff-level move ties it to an SLO: "our read p99 budget is 20ms and we serve from three regions, so I cannot afford a cross-region quorum on the read path; I choose EL (nearest-replica reads) and layer session guarantees for the cases that need read-your-writes."

Table

PACELC reads: if P → (A or C), else E → (L or C). The highlighted column is the half CAP leaves out and the half you pay for constantly, because partitions are rare while the else-case is every single request.

System	If partitioned	Else (no partition)	What that costs in practice
DynamoDB	PA: stay available	EL: favour latency	Nearest-copy read, which may be stale
Cassandra	PA: stay available	EL or EC, per query	Tunable at the call site: ONE is EL, QUORUM is EC
Spanner	PC: keep consistency	EC: favour consistency	Quorum plus commit-wait on every commit
CockroachDB	PC: keep consistency	EC: favour consistency	A Raft quorum per range, on every write

Recap: PACELC extends CAP with the else-case, the latency-vs-consistency tax paid on every request even with no partition, because linearizable reads and writes need leader or quorum round trips; DynamoDB and Cassandra are PA/EL while Spanner and CockroachDB are PC/EC, and the senior move is tying the L-vs-C choice to a concrete latency SLO.