CAP Theorem

Each letter has a narrow meaning in the proof, and it is narrower than the everyday word.

• C, consistency, means every read returns the most recent completed write, as if there were only one copy of the data. The formal name is linearizability. It is not the C in ACID, which is about a transaction keeping the database's rules, such as a balance never going below zero.
• A, availability, means every request that reaches a node that has not crashed gets an answer to its question sooner or later. A node that waits forever, or only replies "try again later", is not available in this sense.
• P, partition tolerance, means the system keeps working by its own rules even when the network loses or delays messages between nodes. A network partition is any such split. It can be a failed switch, a cut cable, or a cloud zone that cannot reach another. It can even be a node so slow that the others give up on it.

The proof is short. Take two nodes that cannot reach each other. A client writes a new value to the first. Another client then asks the second node for that value. The second node cannot know about the write, because no message can reach it. It has only two moves. It can answer with what it has, which may be old, giving up C. Or it can refuse until it can check, giving up A. Nothing a programmer writes can give it a third move.

To see the theorem happen rather than describe it, I ran a three-node etcd cluster in Docker on 2026-10-04. etcd is the small, strongly consistent key-value store that Kubernetes keeps its state in. Its nodes agree on every change using Raft, a consensus protocol. In Raft, a change counts only once a majority of nodes have accepted it: here, 2 of 3.

I wrote price = 100 and checked that all three nodes had it. Then I used docker network disconnect to cut the leader, e2, off from the other two. Nothing crashed. Every process kept running; only the network between them was gone. In the commands below, ctl n is my shorthand for running etcdctl, etcd's command-line client, inside node n, talking to that node only.

Four seconds later, the two connected nodes had elected e3 as the new leader; the Raft term moved from 2 to 3. They then accepted a write. The cut-off node behaved as CAP predicts for a system that chooses consistency. It would not accept the write of 999, because it could not get a majority to agree. It would not even answer a normal read, because it could not prove 100 was still the latest value. Both requests ran out the 3-second limit I gave them. That is C kept and A given up, on that node.

The last command is the interesting one. Asked for a serializable read, which etcd's documentation says "may access stale data with respect to quorum", the same node answered at once: 100. The rest of the cluster had already moved on to 120. That is A chosen and C given up, for that one request. Same node, same moment, two different answers to the CAP question, chosen by the client.

People still use the labels as shorthand, so here is what they mean in practice, with the caveat above.

• CP behaviour: during a partition, the side that cannot reach a majority refuses rather than risk a wrong answer. Some users get errors or timeouts; nobody gets old data. Coordination stores built on consensus, such as etcd, ZooKeeper and Consul, work this way by default.
• AP behaviour: every reachable node keeps answering, and the copies are reconciled after the network heals. Nobody is turned away; some users see stale data, and two sides can accept conflicting writes that must be merged later. Cassandra and DynamoDB lean this way by default, and both let you ask for stronger reads per request.

Choose by asking what a wrong answer costs compared with no answer. A bank balance, a stock count you are about to sell, a lock, a leader election: a wrong answer is worse, so refuse. A product page, a social feed, a view counter, a shopping cart: a slightly old answer is better than an error, so keep answering. Many systems make both choices, one per kind of data.

CAP is a good way to reason about one question: what should this request do when its node is cut off? It is a poor tool for most other questions people bring to it.

• It says nothing about a single-node database. A lone PostgreSQL server has no network between copies to fail, so CAP does not apply until you add replicas.
• It says nothing about speed. A system can satisfy C and still be too slow to use; that is PACELC's territory.
• It does not rank databases. Most real systems can be set per request, and their default is often neither strictly C nor strictly A. A one-letter label hides more than it tells.
• Its consistency is only one level. There are many weaker but useful guarantees, such as read-your-writes or eventual consistency, that CAP does not distinguish.

This page gives you the theorem and one real partition. My CAP Theorem lesson goes further. It walks through the Jepsen test in which MongoDB lost acknowledged writes during a partition, and the setting that fixes it. It also covers tunable consistency in Cassandra, query by query, and PACELC for specific databases.