The most-quoted and most-misunderstood result in distributed systems. CAP does not say 'pick two of three' — it says something far narrower and far more useful: when the network partitions, you must choose between staying consistent and staying available, and you cannot have both. This lesson states the theorem correctly, kills the 'two of three' meme, extends it with PACELC (the part that matters on the 99.9% of days there is no partition — the everyday trade of latency against consistency), and shows why a single-node system like Fable's sidesteps the whole thing by not being distributed at all.

CAP, PACELC, and what consistency actually costs

The moment your data lives on more than one machine — replicas, shards, a multi-region cluster — you inherit a constraint that no amount of engineering removes. It's usually stated as the CAP theorem, and it's usually stated wrong. Getting it right is the foundation of the whole consistency stage, because almost every distributed-database decision is a specific answer to the question CAP actually poses.

The theorem, stated correctly

CAP names three properties of a distributed system:

Consistency (C) — every read sees the most recent write. (This is a specific, strong meaning — linearizability — and note it is not the "C" in ACID, which is a different idea. Same letter, unrelated concept. The overloading is a genuine source of confusion.)
Availability (A) — every request to a non-failed node gets a (non-error) response, even if it might be stale.
Partition tolerance (P) — the system keeps working when the network partitions: messages between nodes are dropped or delayed, splitting the cluster into groups that can't talk to each other.

The popular framing — "pick two of the three" — is misleading to the point of being wrong. Here's why: in any real distributed system, partitions happen. Networks drop packets, links fail, switches reboot. You do not get to choose partition tolerance; the network chooses for you. So P is not optional — it's a fact of life. That collapses the "choose two" into a much sharper statement:

When a partition occurs, you must choose between Consistency and Availability. You cannot have both — during the partition.

That's the whole theorem. It's not a menu of three; it's a single forced choice that only fires during a partition, between the two things you'd actually like to keep.

Why the choice is forced

The intuition is a two-second thought experiment. Two nodes, normally in sync, and the link between them dies — a partition. A write arrives at node A. Now A has exactly two options:

Accept the write and answer the client (stay available) — but node B, cut off, can't learn about it, so a read on B returns stale data. You've sacrificed consistency.
Refuse the write (or refuse to serve reads it can't confirm are current) until the partition heals and it can sync with B (stay consistent) — but now it's returning errors to clients. You've sacrificed availability.

There is no third option. A cannot both acknowledge a write B doesn't know about and guarantee B's reads are current, while they can't communicate. This is why CAP is a theorem and not a guideline — the trade is logically unavoidable, not an engineering weakness.

CP vs AP: two honest choices

So real distributed systems are classified by which they give up during a partition:

CP (consistent, not available under partition) — refuse to serve requests that could violate consistency rather than serve stale or divergent data. A partitioned minority of nodes goes read-only or errors out. You reach for CP when wrong data is worse than no data — a bank balance, an inventory count, a distributed lock. (Consensus systems like ZooKeeper/etcd, and single-leader databases with synchronous replication, sit here.)
AP (available, not consistent under partition) — keep answering on every node even when partitioned, accept that copies temporarily diverge, and reconcile later (the conflict-resolution lesson). You reach for AP when stale data is better than an error — a social feed, a shopping cart, a "likes" count, a DNS record. (Dynamo-style stores like Cassandra sit here.)

Neither is "better." They're answers to "which failure hurts my users less: a wrong answer, or no answer?" — and the right answer differs per feature, sometimes within one product.

Set the two dials, then cause a partition and read from the far side. A CP system refuses (no wrong answer, but no answer); an AP one serves possibly-stale data. Heal the network and the choice shifts to the everyday one — latency vs consistency — which is the part CAP ignores.

If Partition (CAP)

Else, normal ops (PACELC)

Region Awrites here

— healthy link —

Region Byou read here

This system is PC/EC — like etcd / ZooKeeper (fully consistent)

CAP only speaks during a partition: you must give up availability (CP — refuse rather than serve wrong) or consistency (AP — stay up and diverge). But partitions are rare; PACELC adds the everyday clause — else, on a healthy network, you still trade latency vs consistency, because being certain a read is current means coordinating, and coordination is round trips. Neither choice is better; the right one differs per feature — sometimes within one product.

PACELC: the part that matters when nothing is broken

CAP has a serious blind spot: it only says anything during a partition. But partitions are rare — most systems run partition-free 99.9% of the time. What governs behavior on all those normal days? CAP is silent. PACELC fills the gap, and it's the more practically useful framing:

If there is a Partition, choose Availability or Consistency (that's CAP); Else (normal operation), choose Latency or Consistency.

The "else" clause is the everyday one. Even with a perfectly healthy network, a system that wants strong consistency across replicas must coordinate — wait for a write to reach a quorum of nodes, or read from enough nodes to be sure it's current — and that coordination is round trips, which is latency. So even when nothing is broken, you're constantly trading consistency against speed:

EL (else, latency) — don't wait for all replicas; answer fast from the nearest one, accept possible staleness. (Async replication, from the replication lesson, is exactly this.)
EC (else, consistency) — wait for coordination so reads are always current, and pay the latency on every operation. (Synchronous replication is this.)

PACELC is why the read-your-writes bug exists at all: choosing EL (fast reads from a lagging replica) is a consistency sacrifice you made for latency, and it bites on the very next read. Most systems are described by both letters — Dynamo/Cassandra are PA/EL (available and fast, consistency last), a synchronously-replicated Postgres is closer to PC/EC (consistent under partition and normally, latency paid).

The 'CA system' that doesn't exist, and the myth that sinks real designs

The single most common CAP error, and it shows up in architecture reviews constantly: someone labels a system CA — "consistent and available, we just won't tolerate partitions." There is no such thing as a CA distributed system. You don't opt out of partitions; the network partitions whether your design acknowledges it or not, so a "CA" system is really just a CP or AP system that hasn't decided what it does when (not if) the partition comes — which means it will do something unplanned and usually catastrophic: split-brain (the two-primaries-both-writing failure), silent data divergence, or a total hang. Calling a system CA is a confession that its partition behavior is undefined. The only honest labels for a distributed system are CP and AP. (A single-node system can be called CA in the trivial sense that it has no network to partition — which is precisely the point of the next section: the cheapest way to avoid the CAP trade is to not distribute the data.) The practical takeaway: for every stateful component, answer out loud, "when the network splits, do we return stale data or return errors?" If you can't answer, you haven't designed the system — you've drawn a diagram.

Where this lives in Fable

Fable's most consequential consistency decision is that it refuses to make one — it keeps the system of record on a single node, so the CAP trade never fires. There's one managed Cloud SQL Postgres; with no second replica accepting writes, there's no partition between replicas to survive, and reads are trivially current. In CAP's terms that's the degenerate "CA" case — legitimate precisely because it isn't distributed. This is the correct call for a money ledger: the whole product promise is that balances are exactly right, so wrong data is far worse than a brief error — the textbook reason to refuse AP. If Fable ever needs write availability across regions and reaches for a distributed database, this lesson says the honest choice is CP (fail writes during a partition rather than let two regions diverge on who-owes-whom), and I'd take the availability hit knowingly. The PACELC "else" clause already showed up in Fable's history, though: the Singapore→Mumbai migration was an EL-vs-latency decision in miniature — the database was consistent either way, but sitting it far from the API paid a latency tax on every request, and the fix was co-location, i.e. buying back latency without touching consistency. The one place eventual consistency legitimately lives in Fable is the CDN-cached media and any future read replica — both AP/EL by nature, both holding data where stale-for-a-moment is harmless. Consistency where it's money; eventual where it's a cached image. That split is the CAP/PACELC decision, made per data type.

Go deeper

Eric Brewer — "CAP Twelve Years Later: How the Rules Have Changed" — The author of CAP correcting the "two of three" misreading himself, and explaining that the real choice is C-vs-A only during partitions — the definitive primary source for this lesson.
Daniel Abadi — "Consistency Tradeoffs in Modern Distributed Database System Design" (PACELC) — The paper that introduced PACELC and argues why the else-latency-vs-consistency clause matters more day-to-day than CAP itself — short and clarifying.
Jepsen — consistency models map — A rigorous, interactive map of exactly what "consistency" can mean, which the next lesson expands — the antidote to using the word loosely.

Check yourself

Answer out loud, as if an interviewer asked. If you hand-wave, reread that section.

State the CAP theorem correctly, and explain precisely why "pick two of three" is the wrong framing — including why partition tolerance is not actually a choice.
Walk through the two-node partition thought experiment: a write arrives at one side of a partition, and show why the node must sacrifice either consistency or availability, with no third option.
Define CP and AP by the question "which is worse for my users, a wrong answer or no answer?" Give a feature that should be CP and one that should be AP, and justify each.
CAP is silent when there is no partition. Explain what PACELC adds, what the "else" clause trades, and why that clause is behind the read-your-writes bug from the replication lesson.
Someone proposes a "CA" distributed system. Explain why that label is meaningless for anything with a network, and what a system so labeled will actually do when a partition occurs.
Fable keeps its ledger on a single node and calls that correct. Explain how that sidesteps the CAP trade entirely, why a money ledger specifically wants CP rather than AP if it ever distributes, and where eventual consistency still legitimately lives in the app.

CAP, PACELC, and what consistency actually costs

CAP, PACELC, and what consistency actually costs

The theorem, stated correctly

Why the choice is forced

CP vs AP: two honest choices

PACELC: the part that matters when nothing is broken

Go deeper

Check yourself

On this page