The theorem, stated properly
The common phrasing — "pick two of three" — is catchy and wrong in a way that matters.
Splits aren't a design choice. Networks fail: cables are cut, switches reboot, a cloud uptime zone turns unreachable. Any system spanning more than one machine will be split eventually, so P isn't optional.
What the theorem really says is narrower and more handy:
> When a split occurs, you must choose between agreement and uptime.
That is it. When the network is healthy, a system can be both steady and available, and most are. The theorem constrains action during a exact, temporary failure.
The choice, concretely
Two nodes can no longer talk. A write arrives at one of them.
CP — refuse. Return an error, because confirming a write the other side can't see risks two different answers to the same question. Correct, and temporarily down to whoever can't reach a quorum.
Choose this when a wrong answer is worse than no answer: account weighs, inventory that must not oversell, any of it involving money or safety.
AP — accept. Take the write locally, serve reads from local state, and merge when the split heals. Always answering, and during the split two clients can see different values.
Choose this when an answer now is worth more than a just right current one: a shopping cart, a social feed, a view counter, a DNS record. Amazon's first Dynamo paper made this arg for carts by name — a cart that at times resurrects a deleted item is better business than a cart that is at times down.
Step the timeline above through both settings and the difference is one choice 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 use. 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 shows splits, and splits 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 each write with remote replicas — steady and slower — or confirm locally and replicate afterwards — faster and briefly stale.
That is just the synchronous versus asynchronous replication choice, and unlike CAP's trade it's live on each request.
That "live on each request" is the whole reason the extension earns its keep. A split is a rare event. The network between healthy nodes works the vast majority of the time — so CAP's agreement-or-uptime choice is one you really pay only during those rare failures. The latency-or-agreement choice, by contrast, is paid on *each single request* the system ever serves. PACELC is "the more handy version" just 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's worth seeing because it's how a single system offers both answers.
Keep N copies of each row. Let a write wait for W of them to confirm, and a read collect answers from R of them and take the newest. The read is ensured to see the latest write when the read set and the write set must share — which is just 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 ensured-current one is nothing but how many replicas each op 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 shares by one replica *and* still ends with a single node down, where the R = 1 and R = 3 rows each give up uptime on one side. This is just what Cassandra's ONE / QUORUM / ALL levels and DynamoDB's strongly-steady reads are selecting.
Questions people ask about the CAP Theorem
What do the letters in CAP stand for? Consistency, Availability and Partition tolerance.
Can I really only pick two of the three? Not quite. Partitions happen on real networks, so the choice is what to give up during a partition: consistency or availability.
What does a CP system do during a partition? It refuses some requests, or returns errors, to avoid serving inconsistent data.
What does an AP system do during a partition? It keeps answering from each side, accepting that replicas may disagree until they can be reconciled later.
What is PACELC? It extends CAP: if there is a Partition, choose Availability or Consistency; Else, choose Latency or Consistency. It covers the normal case too.
What does R + W > N mean? With N replicas, reading from R and writing to W of them such that R + W exceeds N guarantees every read overlaps the latest write.
Where it goes wrong with the CAP Theorem
"We chose AP, so we gave up agreement." You gave up linearisability during splits. Most of the time the system is steady.
Confusing CAP's C with ACID's C. Different properties.
Calling a single-node DB CP. With one node there's no split and the theorem doesn't apply.
Treating the labels as fixed. Many systems are tunable per query — Cassandra's agreement levels, DynamoDB's strongly steady reads — so the choice belongs to the op, not the product.