What is the CAP theorem, and how do you use it in a design?

The 30 second answer

CAP says that when a network partition splits a distributed system, each side must choose: refuse some requests to stay consistent, or keep answering and risk stale or conflicting data. Partitions aren't optional, so it's really C versus A during a partition, not pick any two. I make that choice per operation: payments and inventory stay consistent, while browsing and recommendations stay available.

The three properties, in the sense of the proof.

Consistency (C): every read sees the most recent write, as if there were a single copy of the data. This is linearizability, which is not the same thing as the C in ACID.
Availability (A): every request to a node that has not failed gets a response, not an error or a timeout.
Partition tolerance (P): the system keeps working even when the network drops or delays messages between nodes.

Gilbert and Lynch proved that no system can guarantee all three in an asynchronous network: if a partition separates two replicas, a write on one side cannot reach the other, so the other side must either answer with possibly stale data (giving up C) or refuse to answer (giving up A).

Why "pick two of three" is misleading. Eric Brewer, who proposed the conjecture, wrote in 2012 that the "2 of 3" formulation was always misleading. In a real distributed system partitions will happen, so P is not something you can drop. And because partitions are rare, there is little reason to give up C or A while the system is healthy. The real question is: what does this operation do during a partition?

How I use it in a design. I choose per operation, not per system:

Prefer consistency (CP behaviour) where acting on stale data costs money or breaks invariants: payments, the last unit of stock, seat booking, unique usernames. During a partition the minority side rejects or delays these requests; a consensus-based store (Raft or Paxos majority writes) gives exactly this.
Prefer availability (AP behaviour) where a slightly stale answer is better than an error: product browsing, search results, recommendations, view counters, shopping-cart adds that can be merged later. These accept writes on both sides and reconcile afterwards with versions, last-writer-wins or merge rules.

A good answer names the concrete behaviour: "if the database's primary is unreachable, checkout returns an error and asks the user to retry, but the product page keeps serving from replicas and cache with a 'price may have changed' check at checkout."

Common mistakes interviewers listen for.

Calling a single-node database "CA". CAP is about replicated systems; one node has no partition between replicas, so the theorem does not apply to it.
Treating C in CAP as C in ACID. ACID consistency means the transaction keeps integrity constraints; CAP consistency means all replicas look like one copy.
Labelling a whole product "AP" or "CP". Many stores let you choose per request, for example with quorum settings for reads and writes.

Alternate interview scenarios

"What about when there is no partition? Is CAP the whole story?"

No, and this is where PACELC helps. Daniel Abadi's formulation says: if there is a Partition, choose between Availability and Consistency; Else, in normal operation, choose between Latency and Consistency. Keeping replicas strongly consistent means waiting for other nodes on every write or read, which costs latency even when the network is fine. Abadi calls systems that give up consistency in both cases PA/EL, and systems that refuse to give it up in both cases PC/EC. For a design this means stating two choices: what happens during a partition, and how much latency you accept for consistency the rest of the time, for example synchronous replication for orders and asynchronous replicas for read-heavy pages.

"Explain CAP and ACID together."

They answer different questions. ACID describes one transaction on one database: all-or-nothing, constraints kept, isolation between concurrent transactions, and durable once committed. CAP describes what replicas of the data can promise when the network between them fails. A system can be fully ACID on each node and still have to choose between C and A across nodes during a partition.

Sources (3)