CAP gets cited in every system design interview and misunderstood in most. Here's what it actually says, what it doesn't say, and what it means for your design decisions.
Eric Brewer's CAP theorem is one of the most-cited and most-misunderstood ideas in distributed systems. Interviewers ask about it constantly. Candidates answer that 'you can only pick two of three' and then stall. The theorem is real and important. But what it actually says is narrower and more precise than the pop-science version, and knowing the difference changes how you design systems.
The theorem states: a distributed data store cannot simultaneously guarantee Consistency, Availability, and Partition Tolerance during a network partition. Consistency here means linearizability: every read returns the result of the most recent write, as if the system were a single node. Availability means every request receives a response (not an error). Partition Tolerance means the system continues to function when network messages are delayed or lost between nodes. The key word is 'during'. CAP is not a general three-way trade-off you make at design time. It's a statement about what happens when a partition occurs. And partitions always occur eventually (dropped packets, slow networks, overloaded switches). So the real choice is: when a partition happens, do you sacrifice consistency (let nodes serve potentially stale reads) or availability (reject requests until the partition heals)?
A common interview answer is to claim CA systems (Consistent and Available, not Partition Tolerant) as a valid choice. This is misleading. Any system that runs on a network is subject to partitions. You cannot opt out of network failures. Claiming to be CA means you have simply decided to ignore partitions and hope they don't happen. Traditional single-node relational databases are sometimes called CA systems, which makes sense only in the tautological sense that a single node has no partition to worry about. The moment you add replication or distribute across multiple nodes, CAP forces a real choice.
CP systems (Consistent, Partition Tolerant) reject writes or reads during a partition rather than serve stale data. HBase, ZooKeeper, and etcd are CP. If you ask etcd for a key during a partition, it may return an error rather than potentially stale data. AP systems (Available, Partition Tolerant) continue to serve requests during a partition, accepting that different nodes may serve different data. Cassandra, DynamoDB, and CouchDB are AP. A write to Cassandra may not yet be visible on all replicas when a read fires, but eventually it will be. The choice is application-driven: a bank account balance requires CP (you cannot serve stale balances). A social feed works fine with AP (seeing a post from three seconds ago instead of one second ago is imperceptible).
CAP only addresses behavior during partitions. Daniel Abadi proposed PACELC to cover the normal (no partition) case too: during a Partition, choose between Availability and Consistency; Else (normal operation), choose between Latency and Consistency. This is more practically useful. Cassandra is PA/EL: available during partitions, and low latency (at the cost of consistency) in normal operation. Spanner is PC/EC: consistent during partitions, and consistent (at the cost of latency) in normal operation. The PACELC frame is why Spanner's writes feel slow: it synchronously replicates across regions, paying latency for consistency in every case, not just during partitions.
When an interviewer asks about CAP, the correct answer walks through what happens at partition time: if we have a write going to node A while node B can't reach A, do we let B accept reads (AP) or reject them until the partition heals (CP)? Then explain your application's tolerance for stale data. A social timeline can tolerate stale reads, so design AP. A payment system cannot, so design CP. The trap is treating CAP as a product brochure claim ('we are CP') rather than a consequence of concrete design choices about how partitions are handled.