PACELC

Pradeep P
2 days ago
3 min read

Series: Modern System Design · Layer 3 — Reliability

Layer 3 · Post 18 of 21

← Previous: FLP Impossibility → Next: Split-Brain

Layer 3 — Reliability · Post 102 of 119

CAP only talks about partitions. PACELC adds the everyday tradeoff: even when the network is fine, you still pick latency or stronger consistency.

What you'll learn

How to read PACELC as two sentences, not a logo
Why "we are CP" does not tell you what a healthy cluster feels like
How to map Dynamo, Postgres, and Spanner onto PA/EL vs PC/EC

The idea in one minute

PACELC (Abadi): if there is a Partition, choose Availability or Consistency (that is CAP). Else — no partition — choose Latency or Consistency.

Partition?  --yes-->  AP  or  CP     (CAP)
            --no--->  EL  or  EC     (the daily tax)

EL: optimize for latency (local reads, async replication, eventual). EC: pay round trips for stronger consistency (sync to a quorum, linearizable reads).

Post 38 said CAP is a failure story. PACELC is the happy-path story people forget: a globally replicated database that waits for two regions on every write chose EC. One that returns after the local AZ chose EL (and a weaker read).

Why it matters

Interview CAP answers often stop at "when the cable is cut." The follow-up is: and when it isn't? If every read is R=1 from the nearest replica, you chose latency. If every read is R=ALL or a linearizable lock(), you chose consistency. Both can be the same product's knobs.

This is also how you talk about multi-region (Post 60) without waving CAP as a vibe.

How it works

PA/EL: stay up in a split, and when healthy prefer speed. Classic Dynamo, Cassandra with ONE, many caches, DNS. You repair later (read repair, CRDTs, last-write-wins).

PC/EC: refuse or stall in a split, and when healthy still wait for a quorum / primary. etcd, ZooKeeper, Postgres synchronous replica, Mongo majority, Spanner-style commit.

PA/EC or PC/EL exist as mixed designs: e.g. available in partition for some keys, but strongly consistent when the cluster is whole — or CP in partition but async (EL) in normal times, which is a dangerous combo if you thought sync meant CP.

Latency here is user-visible wait, not "the network is slow so CAP doesn't apply." Extra replica hops are PACELC-L.

Not a third CAP letter. It is CAP plus the else-branch. You still do not "pick CA" on a real network (Post 38).

A simple example

User profile store, two regions.

EL: write in the nearest region, async replicate. Profile save feels instant. The other region may show the old avatar for 200 ms (or 2 s under load). Partition: both regions keep taking writes (PA) — merge later.

EC: write waits until the other region (or a majority) acks. Save is 40–80 ms farther. Reads can be linearizable. Partition: one side stops writes (PC).

A social app often ELs avatars and ECs "change password." PACELC is allowed to be per API, not one sticker on the company.

Common mistakes

Stopping at CAP. Then you cannot explain why Spanner is slow-ish when the world is fine.

Calling Cassandra "PACELC" as if that picked the knobs. Cassandra is a slider (ONE vs QUORUM). Say the consistency level.

EL as "we don't care about data." You still need a repair story (Post 44).

Using PACELC to dodge SLOs. "We're EL" is not permission for 5-minute replica lag without a dashboard.

How this shows up in real systems

DynamoDB: eventually consistent vs strongly consistent reads — EL vs EC on the same table.
Aurora / RDS sync replica: EC-leaning writes; promote behavior is the P branch.
Cockroach / Spanner: EC serializable as the default tax; locality configs try to shrink L.
Redis async replica: EL; WAIT is you opting into more C.

Recap

Partition → A or C. Else → L or C.
Healthy-path sync replication is PACELC, not a CAP loophole.
Next: the partition failure mode that makes the P branch real — split-brain.