The three letters
- Consistency: every read sees the most recent write (or an error).
- Availability: every request gets a non-error response.
- Partition tolerance: the system keeps working when the network splits the nodes.
The theorem says you can only guarantee two of the three. The common phrasing — "pick two" — is where most explanations go off the rails.
The detail most resources get wrong
Partition tolerance is not optional. Networks fail. If you are running a distributed system, you do not get to choose against P. The real choice is: when a partition happens, do I sacrifice C or A?
So "CA" is not a meaningful design. In practice the trade-off is:
- CP: during a partition, refuse requests that cannot be served consistently. Favor correctness over uptime.
- AP: during a partition, accept requests and serve possibly-stale data. Favor uptime over correctness.
Rephrase the question from "pick two" to "when the network breaks, do you stop serving, or do you serve stale?" That is the actual decision.
Examples that clarify
- Bank transfers: CP. If a partition means we cannot confirm balances consistently, reject the transfer. Better no transfer than a double spend.
- Shopping cart: AP. If a partition means we cannot sync carts across regions, let the user keep shopping. Reconcile later.
- DNS: AP. Stale records are fine; unreachable DNS is catastrophic.
- Leader election / distributed locks: CP. Two leaders at once is worse than no leader.
Where CAP is a poor model
The theorem treats consistency as binary. Reality is a spectrum: read-your-writes, monotonic reads, session consistency, bounded staleness, causal consistency, eventual. Modern databases let you pick per-operation.
PACELC extends CAP: "when Partitioned choose A or C; Else, in the normal case, choose Latency or Consistency." This is more useful because most of the time there is no partition, and the interesting trade-off is latency vs. freshness. A system can be AP during partitions and prefer low-latency stale reads in normal operation (DynamoDB by default), or CP and consistent even in normal operation (Spanner).
How to use CAP in an interview
When asked to pick a database, do not cite CAP as the reason. Say: "This workload needs X consistency and tolerates Y latency. During a partition we accept Z behavior. That points me at…"
Answering via the shape of your needs is much stronger than "NoSQL is AP, so I pick Cassandra." Cassandra is tunable — you can run it very differently depending on your replication factor and consistency levels. The label hides the real choice.
The one-line summary
CAP is not a menu. It is a reminder: when the network fails, the system does one of two things — fails requests or serves stale data. Know which one your product needs, and why.