The CAP Theorem (and PACELC)

Part three of the series, and the most misquoted idea in system design. The CAP theorem gets summarized as “pick two of three,” which is wrong in a way that actively misleads. Let me state it correctly, because once you see the real shape it’s simple — and it governs every distributed data decision you’ll make.

The three letters

CAP is about a system that keeps data on more than one machine. Three properties:

• Consistency (C) — every read sees the most recent write. All nodes agree on the current value. (Note: this is a stronger C than the one in database ACID — here it means “linearizable,” a single up-to-date view.)
• Availability (A) — every request gets a non-error response, without guaranteeing it’s the latest data. The system always answers.
• Partition tolerance (P) — the system keeps working when the network drops or delays messages between nodes.

Why it’s not “pick two”

Here’s the correction that makes it click: partitions are not optional. A partition is a network failure — a switch dies, a cable is cut, a datacenter link saturates — and you don’t get to choose whether networks fail. They fail. So P is not a choice you make; it’s a condition reality imposes. Any system whose data lives on multiple machines will experience partitions.

That collapses the “three choices” into one real decision. Given that a partition will happen, and in that moment two nodes can’t talk to each other, you have exactly two options:

• Refuse to answer until you can guarantee the data is current → you kept Consistency, you gave up Availability. (CP)
• Answer with whatever you have locally, possibly stale → you kept Availability, you gave up Consistency. (AP)

That’s the whole theorem. During a partition, choose C or A. “Pick two of three” is folklore; the truth is “P is mandatory, so pick C or A for when P strikes.”

Network partition happens (not if — when):

  Node A ─ ─ ✂ ─ ─ Node B     the two can't talk

  CP: "I won't answer unless I'm sure I'm current."  → consistent, unavailable
  AP: "I'll answer with my local copy."              → available, maybe stale

“CA” is a category error

Vendors love to claim “CA” — consistent and available. There’s no such thing in a distributed system. A single-node database is trivially “CA” because it has no partitions to tolerate — but the instant you add a replica for redundancy or scale, partitions become possible and you’re back to choosing C or A. “CA” just means “one machine,” and one machine has its own problem: it’s a single point of failure. Don’t let a marketing page sell you CA as a distributed guarantee.

CP and AP in the wild

Neither choice is “better” — they fit different jobs:

The choice follows the cost of being wrong versus the cost of being down, per datum:

• A bank balance or a clinic appointment slot is CP territory. Double-booking one slot because two nodes each thought it was free is a real-world mess. Better to say “try again in a moment” than to confirm two patients into the same 3pm.
• A like count, a “last seen” timestamp, a social feed is AP territory. If your like count is briefly off by three, nobody is harmed, and refusing to load the page would be absurd. Availability wins.

Crucially, this is a per-feature decision, not a whole-system one. The same product can — should — be CP for payments and AP for the activity feed.

PACELC: the tradeoff that bites when nothing is broken

CAP only talks about behavior during a partition, which is rare. PACELC extends it to the 99.9% of the time the network is healthy, and it’s the more practically useful framing:

Partition → A or C; Else (normal operation) → Latency or Consistency.

Translation: even with a perfectly healthy network, keeping replicas consistent costs latency — because a write has to reach and be acknowledged by other nodes before it’s confirmed. So you’re always trading, partition or not:

• PC/EC systems (e.g. traditional RDBMS with synchronous replication) choose consistency in both cases and pay latency for it.
• PA/EL systems (e.g. Dynamo-style stores, Cassandra) choose availability and low latency, accepting staleness.

PACELC is why “just make it consistent” is never free. The bill arrives as latency on every single request, not just during the rare partition — which is exactly the latency-vs-consistency axis from the intro, now with a name.

Caveats and best practices

• Decide C-or-A per feature, not per system. The instinct to make everything strongly consistent is how you get a slow app; the instinct to make everything eventually consistent is how you double-book appointments. Sort your data by cost-of-wrong.
• Most single-app products are simpler than this makes them sound. One primary MySQL database is effectively CP and perfectly correct for the vast majority of apps. You meet CAP for real when you add replicas, multi-region, or a distributed store — know it’s coming before you get there.
• Distrust any “CA” claim. It means single-node (with its own SPOF problem) or it means the vendor is redefining a word. Ask what happens during a network partition, specifically.
• Remember PACELC on the happy path. If someone proposes synchronous cross-region replication for “safety,” the cost is latency on every write, forever — not just during failures. That may be worth it; make sure it’s a decision, not an accident.

Conclusion

P is mandatory → networks fail; you don't opt out of partitions
During a partition → choose C (refuse, stay correct) or A (answer, maybe stale)
"CA" → means one machine (its own SPOF), not a distributed guarantee
PACELC → even healthy, consistency costs latency — you're always trading
Apply → CP for money/bookings, AP for feeds/likes; decide per feature

CAP isn’t “pick two of three” — it’s “the network will break, so decide now whether that moment makes you unavailable or inconsistent.” PACELC adds that you’re paying a smaller version of that bill on every request anyway. Next: consistency models — the menu of options between “always current” and “eventually, probably, current.”