the CAP theorem
/ CAP /
Suppose you run a service on several machines that each keep a copy of the same data, so it stays available even if one machine dies. Now a network cable between two groups of your machines gets cut — the groups can still each serve users, but they can no longer talk to each other. A customer updates their address on the group on the left. Should the group on the right, which has not heard the update, answer a request for that address? The CAP theorem (named for Eric Brewer) says you cannot dodge this dilemma: when the network is partitioned, you must choose.
CAP names three desirable properties. Consistency (C): every read sees the most recent write, so all copies look the same — everyone agrees on the data. Availability (A): every request gets a (non-error) answer, the system always responds. Partition tolerance (P): the system keeps working even when the network drops messages between nodes. The theorem's real content is sharp: when a partition (P) actually occurs, you cannot have both C and A at once. You either refuse to answer on the side that might be stale (choosing consistency, sacrificing availability) or you answer with possibly-old data (choosing availability, sacrificing consistency). The popular slogan 'pick two of three' is a simplification; the honest version is 'during a partition, pick C or A'.
Why it matters, and the common misreadings: CAP forces an explicit, business-level decision. A bank balance had better choose consistency (better to show an error than the wrong balance), while a social feed can choose availability (better to show a slightly stale post than nothing). Two cautions worth stating plainly: first, partitions are not optional in the real world — networks do fail — so P is essentially mandatory, which is why the real choice is between C and A. Second, when there is no partition, a well-built system can offer both strong consistency and high availability; CAP only forces the trade-off during the failure. CAP is also a coarse, intro-level lens: finer models (like PACELC) add that even without partitions you trade latency against consistency.
A shopping cart is replicated in two data centers and the link between them fails. A CP choice: the cart in the cut-off center returns errors until the link heals, so you never see a wrong cart. An AP choice: both centers keep accepting changes, and when the link heals their carts must be merged — you stayed available but briefly risked inconsistency. Neither is 'right'; it depends on the product.
During a network partition you must choose: stay consistent (refuse) or stay available (risk stale).
Beware the lazy reading 'pick any two of three'. Partitions are a fact of life, so P is forced; the genuine choice is C versus A, and only while a partition lasts. With no partition, you can have both.