Picture an online shop running in two regions, with replicas on both sides of an ocean. One afternoon the link between the regions goes down. Both sides are healthy, both are still taking traffic, and neither can see the other. A US customer buys the last unit of a product at the same moment an EU customer buys it. CAP explains the forced choice the system must make next. In plain terms: while a network failure keeps copies of the same data from talking to each other, each operation can either stay consistent, refusing to answer on the side that cannot confirm the latest write, or stay available, answering on both sides and accepting that they may disagree. It cannot do both until the link heals.

CAP addresses a specific choice during a network partition. In interviews, it usually comes up when the interviewer cuts a link on the whiteboard and asks what your design does next. Budget a minute or two to state the claim and choose how the affected operation behaves. At mid-level, that is usually enough.

Reach for it whenever the same data lives on more than one machine or region and the design must say what happens when they lose contact. It is the wrong tool for a single database node, where there are no copies to split, for latency trade-offs on a healthy network (PACELC in chapter 4 covers those), and for choosing a database product, since a CP or AP label on a whole product hides choices made per operation.

At senior level, include the boundaries too: what the chosen side costs, and why the choice belongs to an operation rather than a whole system. The multi-region shop follows us throughout because it has both kinds of data the theorem covers: inventory counts and account balances that must not disagree, and product listings and review counts that can be stale for a while without causing harm.