Two impossibility theorems that constrain every distributed data system. CAP is the famous one. PACELC is the more useful one. Both will show up in your interview, and you should know exactly when each lies to you.
Learning objectives
State what CAP says and why "CA" is not a real choice in distributed systems
Explain how PACELC extends CAP by describing the everyday (non-partition) latency trade-off
Place real systems (Spanner, Cassandra, DynamoDB, MongoDB) in the correct PACELC quadrant
Distinguish the five consistency levels and know the latency cost of each
⏱ 14 min◆ 4 simulations✦ +95 XP available
The theorem, restated honestly
Three nodes. A network split. You must choose: do reads stay correct, or do reads stay possible? CAP says you can't have both. Real designs make this choice per-table, per-API, per-millisecond.
The CAP theorem was published by Eric Brewer in 2000 and proved by Gilbert and Lynch in 2002. In a distributed system, when a network partition happens — two nodes can't talk to each other — you must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response). You cannot have both, simultaneously, during a partition. There is no design that beats this.
The version interviewers actually want is sharper: "CA" is not a real choice. Real networks partition. Cables fail, switches reboot, regions get hurricane'd. P is not a knob; it's a fact. So the real question CAP asks is: when (not if) we partition, which do you give up — C or A?
Pick a partition trade
Three replicas, sharing writes. Cut the network between them and watch what each design does. Click the trade you'd accept.
Fig. 01 · the partition theatreThree nodes · one client · one cableClick Cut cable · then choose CP or AP.
when the cable cuts, you keep…
what happens
Click Cut cable to introduce a partition between
{A} and {B, C}. Then pick the trade-off you'd live with.
controls
Read it like this. A solid edge means a healthy connection. A dashed crimson edge is a dead network link. The ring around the nodes shows the quorum the system can still talk to. CP shrinks the ring (smaller, but still correct); AP keeps everyone live (bigger, but lying).
▸
"CA" is not a real choice. Single-node Postgres is "CA" because there's no network between replicas to partition. Add a replica and you're back to choosing CP or AP.
PACELC: the useful upgrade
CAP only describes the bad day. PACELC describes both: if partition, choose A or C; else, choose Latency or Consistency. The "else" is where your bill lives.
To give a read strong consistency on a multi-region cluster, you have to coordinate across regions — a network round-trip, often 50-150ms. Or you can answer from the local replica in 1ms and risk staleness. Every distributed DB sits somewhere on this 2D plane, and the choice is usually configurable per-query.
Fig. 02 · the PACELC compassTwo trades, four corners, real systems plottedHover dots · click a quadrant.
quadrant
PA/EC
Consistent in normal life, available under partition. The popular default for user-state stores: writes are linearizable when the network is healthy, but if a region splits off, the system keeps accepting writes there and merges later. You trade some staleness for resilience.
partition
availability
else
consistency
The plot. Vertical = the partition trade (top: stay available; bottom: stay consistent). Horizontal = the everyday trade (left: low latency; right: strong consistency). The dot is where each system sits by default — most are tunable per-query.
The latency tax
Every step toward stronger consistency has a price tag in milliseconds. Drag the marker. Watch the bill rise.
Fig. 03 · the latency-tax frontierp99 read latency vs. freshness guaranteeDrag along the curve.
freshness guarantee
read-your-writes
A client always sees its own most recent write. Other clients may see staler data. Implemented with sticky sessions or version pinning.
p99 read latency
8 ms
Cheap. Local-replica read with a session token check.
cluster scope
single region
Stays inside one region's failure domain. No WAN coordination on the read path.
The bill. Latency numbers are typical p99s for a 3-region active-active cluster. Eventual is "best-effort, free." Linearizable means a wide-area quorum on every read — that's the round-trip. The flat plateau in the middle is where most production systems live.
The five flavours of consistency
"Consistency" is one word for at least five guarantees. Click a row to expand. The animation shows how each handles the same write/read sequence.
Fig. 04 · the consistency staircaseSame race, five rules — what does each reader see?A writes x=1 then x=2; B reads x.
The animation. Top lane is writer A's timeline; bottom lane is reader B's timeline. Blue dots are writes; green = read returned a value at-least-as-fresh as expected; crimson = read returned a stale value (allowed by that level's contract).
▸
The interview move. When a question requires "consistency," ask which kind. "Read-your-writes for the user's own session, eventual for everyone else's view" is a perfectly normal design — and a much cheaper one than going linearizable everywhere.