Distributed Systems
The CAP Theorem
In a distributed system, a network partition forces a choice between consistency and availability — you can't keep both.
Updated 2026-06-09
The CAP Theorem
The moment your data lives on more than one machine, you inherit a hard limit. The CAP theorem describes it: when the network between your nodes fails, you must choose between staying consistent and staying available. You cannot have both at that instant.
The three properties
- Consistency (C) — every read returns the most recent successful write, or an error. All nodes agree on the data, as if there were a single copy.
- Availability (A) — every request to a non-failing node gets a non-error response, even if that response might be stale.
- Partition tolerance (P) — the system keeps operating even when the network drops or delays messages between nodes.
Why you can't have all three
The popular phrasing — "pick two of three" — is misleading. In any real
distributed system, partitions are not optional: networks drop packets,
links fail, switches reboot. So P is a given, not a choice.
The real decision happens during a partition. Imagine two nodes that can no longer talk to each other, and a write lands on node A:
- To stay consistent, node B must refuse reads (or error) until it can confirm it has the latest data — so you sacrifice availability. This is CP.
- To stay available, node B answers anyway with whatever it has — possibly stale — so you sacrifice consistency. This is AP.
The choice is only forced while the partition lasts. When the network is healthy, a well-designed system delivers both consistency and availability.
CP vs AP in practice
| Lean | Behavior during a partition | Typical fits |
|---|---|---|
| CP | Reject requests rather than serve stale data | Bookings, ledgers, inventory, configuration/coordination |
| AP | Always answer, reconcile later | Feeds, product catalogs, metrics, shopping carts |
Most production databases let you tune where you sit (for example, per-query read/write quorums), so treat these as defaults and leanings, not fixed labels. Coordination systems like ZooKeeper and etcd lean strongly CP; wide-column and Dynamo-style stores like Cassandra are AP with tunable consistency.
Beyond CAP: PACELC
CAP only describes behavior during a partition. PACELC adds the everyday case: if there's a Partition, choose A or C; Else (normal operation), choose between Latency and Consistency. Even with a healthy network, keeping replicas perfectly in sync costs latency — so the trade-off never fully goes away.
Common misconceptions
- "CAP says pick any two." Not really — you don't get to drop
P. It's C vs A during a partition. - "My single database is CA." A single node isn't a distributed system; CAP doesn't apply until data is replicated.
- "Consistency here means ACID consistency." No — CAP's
Cis closer to linearizability (one up-to-date copy), not theCin ACID.
The takeaway: don't ask "is my system CP or AP?" Ask "when the network splits, which do I want this particular operation to do — refuse, or answer with possibly-stale data?" The answer differs across features in the same product.