The CAP Theorem: Consistency vs. Availability Under Partition
Why every distributed data store eventually has to choose between returning a possibly-stale answer and returning no answer at all.
Intermediate
TopNotchNote
Notes that matter
the three properties
The CAP theorem (Brewer's theorem) is a statement about distributed data systems: you can fully guarantee at most two of the following three properties at the same time.
| Property | Meaning |
|---|---|
| Consistency (C) | Every read receives the most recent write, or an error — no stale data is ever returned. |
| Availability (A) | Every request receives a (non-error) response, without guarantee that it contains the most recent write. |
| Partition tolerance (P) | The system keeps operating even when network failures split it into groups of nodes that can't talk to each other. |
why P isn't really optional
In a single-datacenter, single-machine system, network partitions don't happen, so C and A can both hold. But real distributed systems span multiple machines, racks, and often regions — and networks fail. A cable gets cut, a switch dies, a region loses connectivity. Given that partitions are a fact of life at scale, the theorem in practice isn't really "pick 2 of 3" — it's "partitions will happen, so when one does, pick C or A."
the choice that actually gets made: C vs. A during a partition
Say a data store has two replicas, one in the US and one in the EU, and the network link between them goes down. A write arrives at the US replica. What should a read against the EU replica return?
| Choice | Behavior | User-facing effect |
|---|---|---|
| Favor Consistency (CP) | The EU replica refuses the read (or blocks) until it can confirm it has the latest data. | "Sorry, try again in a moment" — correctness over uptime. |
| Favor Availability (AP) | The EU replica returns whatever it has, even if it's stale. | "Here's the data" — possibly outdated, but the request never fails. |
Neither choice is universally "correct" — it depends entirely on what the data represents. A bank balance check during a partition should probably be CP: an outdated balance could let someone overdraw. A social media feed during a partition should probably be AP: a feed that's a few seconds stale is a far better experience than a feed that refuses to load at all.
a common misreading of CAP worth avoiding
CAP is sometimes summarized as "pick any two of C, A, P," which invites the wrong question — "should we build a CA system?" A CA system, by definition, has no plan for what happens during a partition, which in a real multi-node deployment means it simply becomes unavailable when one occurs. Once P is accepted as non-negotiable at scale, the actual design decision is always C vs. A, not whether P applies.
It's also worth noting CAP describes worst-case behavior during an actual partition, not everyday operation. Well-designed systems often behave with strong consistency and full availability the vast majority of the time, and the CAP trade-off only becomes visible during the rare window when a partition is actually happening.
where this shows up later in this track
This same C-vs-A tension reappears throughout the rest of this section under different names: it's the reasoning behind choosing synchronous vs. asynchronous replication, it's why Dynamo-style key-value stores expose tunable consistency instead of a fixed answer, and it's the underlying reason NoSQL databases as a category tend to favor availability over the strict consistency that relational databases default to.