The CAP Theorem
When the network splits, a distributed store can stay correct or stay answering. It cannot do both.
Overview
What the three letters mean
Consistency here means *linearisability*: every read sees the most recent write, as if there were one copy. It is not the C in ACID, which is about constraints being satisfied. Two different ideas, one letter, endless confusion.
Availability means every request to a non-failed node gets a non-error response. Not "mostly up" — every request, every working node.
Partition tolerance means the system keeps operating when the network drops or delays messages between nodes.
The CAP Theorem
The network between the two nodes is about to fail. Pick a strategy and step through to see what each client experiences.
Worth knowing
The CAP Theorem
The most quoted and most misquoted result in distributed data, and what it actually constrains.
The theorem, stated properly
The popular phrasing — "pick two of three" — is memorable and wrong in a way that matters.
Partitions are not a design choice. Networks fail: cables are cut, switches reboot, a cloud availability zone becomes unreachable. Any system spanning more than one machine will be partitioned eventually, so P is not optional.
What the theorem actually says is narrower and more useful:
> When a partition occurs, you must choose between consistency and availability.
That is it. When the network is healthy, a system can be both consistent and available, and most are. The theorem constrains behaviour during a specific, temporary failure.
The choice, concretely
Two nodes can no longer talk. A write arrives at one of them.
CP — refuse. Return an error, because acknowledging a write the other side cannot see risks two different answers to the same question. Correct, and temporarily unavailable to whoever cannot reach a quorum.
Choose this when a wrong answer is worse than no answer: account balances, inventory that must not oversell, anything involving money or safety.
AP — accept. Take the write locally, serve reads from local state, and reconcile when the partition heals. Always answering, and during the partition two clients can see different values.
Choose this when an answer now is worth more than a perfectly current one: a shopping cart, a social feed, a view counter, a DNS record. Amazon's original Dynamo paper made this argument for carts explicitly — a cart that occasionally resurrects a deleted item is better business than a cart that is sometimes unavailable.
Step the timeline above through both settings and the difference is one decision made at one moment.
Reconciling afterwards
An AP system must resolve conflicting versions once the network returns. Last-write-wins is simple and silently discards data when clocks disagree. Vector clocks detect concurrent writes and hand the conflict to the application. CRDTs are data types designed so concurrent updates merge deterministically — which is why counters, sets and collaborative text editors are the AP success stories.
PACELC, which is the more useful version
CAP only describes partitions, and partitions are rare. Daniel Abadi's extension covers the rest of the time:
> if Partition then Availability or Consistency, Else > Latency or Consistency.
The second half is the one engineers meet daily. With the network healthy, a system can still choose to confirm every write with remote replicas — consistent and slower — or acknowledge locally and replicate afterwards — faster and briefly stale.
That is exactly the [synchronous versus asynchronous replication choice](replication_and_lag.html), and unlike CAP's trade it is live on every request.
That "live on every request" is the whole reason the extension earns its keep. A partition is a rare event — the network between healthy nodes works the vast majority of the time — so CAP's consistency-or-availability choice is one you actually pay only during those rare failures. The latency-or-consistency choice, by contrast, is paid on *every single request* the system ever serves. PACELC is "the more useful version" precisely because it names the trade you make billions of times a day rather than the one you make on the bad afternoon a cable is cut.
The tunable, made concrete: R + W > N
The last "where it goes wrong" note below says the labels are tunable per query. That tuning is one inequality, and it is worth seeing because it is how a single system offers both answers.
Keep N copies of each row. Let a write wait for W of them to acknowledge, and a read collect answers from R of them and take the newest. The read is guaranteed to see the latest write whenever the read set and the write set must overlap — which is exactly when R + W > N. Below that they can miss each other, and a read can come back stale.
On N = 3:
| W | R | R + W > N | what you get |
|---|---|---|---|
| 1 | 1 | no | fastest reads and writes, but reads can be stale |
| 2 | 2 | yes | quorum: strong, and survives one node down either way |
| 3 | 1 | yes | strong, instant reads, but a write needs all three up |
| 1 | 3 | yes | strong, instant writes, but a read needs all three up |
Read the W=1, R=1 row against the W=2, R=2 row: same three machines, and the choice between a possibly-stale answer and a guaranteed-current one is nothing but how many replicas each operation waits for. That is the AP/CP dial from earlier, turned per request instead of per system.
Quorum — W = R = 2 — is the common default because 2 + 2 = 4 > 3 overlaps by one replica *and* still completes with a single node down, where the R = 1 and R = 3 rows each give up availability on one side. This is precisely what Cassandra's ONE / QUORUM / ALL levels and DynamoDB's strongly-consistent reads are selecting.
Where it goes wrong
"We chose AP, so we gave up consistency." You gave up linearisability during partitions. Most of the time the system is consistent.
Confusing CAP's C with ACID's C. Different properties.
Calling a single-node database CP. With one node there is no partition and the theorem does not apply.
Treating the labels as fixed. Many systems are tunable per query — Cassandra's consistency levels, DynamoDB's strongly consistent reads — so the choice belongs to the operation, not the product.
Check yourself
0 of …Answer without scrolling back up.
What is wrong with 'pick two of three'?
A CP system during a partition will:
What does the 'ELC' half of PACELC describe?
The CAP Theorem
Consistency here means *linearisability*: every read sees the most recent write, as if there were one copy. It is not the C in ACID, which is about constraints being satisfied. Two different ideas, one letter, endless confusion.