Skip to content
System design course
Ch.2 · The building blocks·concept ·6 min read

The PACELC theorem

CAP only describes failures. PACELC adds the question that matters the other 99% of the time — latency vs consistency when everything is healthy.

What CAP leaves out

CAP only tells you what happens during a partition. But partitions are rare; your system spends almost all its life healthy. PACELC fills the gap by asking what you trade the rest of the time.

The statement

Partition? then A or C. Else (normal operation), Latency or Consistency.

Read as two clauses:

  • If Partition (PA/PC) — same choice as CAP: stay available or stay consistent. (Covered last lesson.)
  • Else / normal operation (EL/EC) — even with no failure, keeping replicas perfectly consistent costs latency (you must coordinate across nodes before answering). So you choose: answer fast from one replica (EL, accept staleness) or coordinate for a fresh answer (EC, accept latency).

Why the “else” clause matters

The everyday tax of strong consistency is coordination latency. To guarantee a read sees the latest write, replicas must agree before responding — a round trip, sometimes across regions. If you don’t need that guarantee, you can answer from the nearest replica immediately and let updates propagate in the background.

This is the real, constant trade-off behind “should this be strongly or eventually consistent?” — and it’s why globally-distributed systems lean toward low latency (EL) for most data.

Classifying real systems

  • Dynamo / Cassandra → PA/EL — available under partition, and even when healthy they favor low latency over strong consistency (tunable).
  • Fully consistent stores (e.g. VoltDB, HBase) → PC/EC — consistent under partition, and pay coordination latency when healthy to stay consistent.
  • Spanner → PC/EC (roughly) — chooses consistency, and uses heavy machinery (synchronized clocks) to keep the latency cost bearable.

The interview takeaway

PACELC’s value is the EL/EC half: it forces you to admit that strong consistency isn’t free even when nothing is broken. When you say “this read can be eventually consistent,” you’re really saying “I’ll take lower latency by reading a possibly-stale local replica” — and PACELC is the vocabulary that makes that precise. Use it to justify reading feeds, profiles, and caches from the nearest replica while routing money and inventory through coordinated, consistent writes.