The CAP theorem is one of the most cited and most misunderstood ideas in distributed systems. The popular version — "pick two of three" — is a useful slogan and a slightly misleading one. The real statement is narrower and more actionable once you understand what it is actually about: what your system does when the network breaks.
What changed in 2026
- Tunable consistency became standard. Leading distributed databases now let you set the consistency level per query, so the CAP tradeoff is a runtime dial rather than a fixed product category.
- PACELC is the framing practitioners use. Teams increasingly reason in PACELC terms — consistency versus latency during normal operation, not just during partitions — because that is the tradeoff they hit daily.
- Geo-distribution made partitions ordinary. As systems span regions by default, network partitions moved from rare edge case to routine event that architecture has to plan for.
What CAP actually claims
CAP names three properties:
- Consistency — every read sees the most recent write (this is linearizability, stricter than the "C" in ACID).
- Availability — every request to a non-failing node gets a non-error response.
- Partition tolerance — the system keeps working even when the network drops or delays messages between nodes.
The theorem: during a network partition, you cannot have both consistency and availability. You must choose. When the network is healthy, you can have both — CAP says nothing about that case.
Why partition tolerance is not really a choice
Here is the part the slogan obscures. Networks partition. Cables get cut, switches fail, regions lose connectivity. If your system spans more than one machine, partitions will happen. So "give up partition tolerance" is not a real option for a distributed system — it just means the system breaks completely when a partition occurs.
That leaves the genuine choice: when a partition happens, do you stay consistent (refuse or block requests that cannot be safely served) or stay available (answer with possibly stale data and reconcile later)?
CP vs AP compared
| Choice |
During a partition |
Good for |
Example use |
| CP (consistency) |
Rejects/blocks writes that cannot be confirmed |
Money, inventory, anything where wrong is worse than slow |
Ledgers, coordination services |
| AP (availability) |
Serves requests, allows temporary divergence |
Feeds, carts, telemetry, anything where stale beats down |
Shopping carts, social timelines |
An AP system that diverges during a partition typically reconciles afterward, which is exactly where eventual consistency comes in: the replicas converge once the network heals.
PACELC: the extension you actually use
CAP only describes partitions, which are rare. PACELC adds the common case: if there is a Partition, choose Availability or Consistency; Else (normal operation), choose Latency or Consistency.
That second clause is the tradeoff engineers face every day. Strong consistency usually means coordinating across nodes, which costs latency. Relaxed consistency lets you answer from the nearest replica, faster. Most tuning decisions in a distributed database are really PACELC-else decisions about latency versus freshness.
Common misconceptions
"Pick two" as a permanent label. CAP is not a fixed identity for a database. It describes behavior during a partition only. The same system can behave differently per operation.
Confusing CAP consistency with ACID consistency. CAP's C is linearizability. ACID's C is about invariants and constraints. They are different properties that share a letter.
Thinking CA is achievable. A single node is CA but not distributed. Any real distributed system must tolerate partitions, so CA is not a meaningful choice.
Believing eventual consistency means broken. AP systems are not incorrect; they trade immediate global agreement for availability and converge afterward.
FAQ
Can a system be both consistent and available?
Yes, when there is no partition. CAP only forces the tradeoff during a partition. The moment the network is healthy again, a well-designed system can offer both.
Is CAP outdated?
The core result is sound but too coarse for daily design. PACELC is the more practical framing because it also covers the latency-versus-consistency tradeoff during normal operation.
Which should I choose, CP or AP?
It depends on the cost of staleness. For money and inventory, prefer CP. For feeds, carts, and telemetry where a stale answer beats no answer, prefer AP. Many databases let you choose per operation.
How does CAP relate to eventual consistency?
Eventual consistency is the reconciliation model most AP systems use: after a partition, replicas exchange updates and converge to the same state.
Where to go next