The CAP theorem says that a networked shared-data system can simultaneously guarantee at most two of three properties: consistency (every read sees the most recent write), availability (every request gets a non-error response), and partition tolerance (the system keeps working even when the network drops or delays messages between nodes). Eric Brewer first stated this as a conjecture in his July 2000 PODC keynote, “Towards Robust Distributed Systems.”
The crucial practical insight is that network partitions are a fact of life in any distributed system, not something a designer can opt out of. Because messages between nodes can always be lost or delayed, a real system must tolerate partitions. That turns CAP from a free three-way choice into a forced two-way one: when a partition happens, the system has to give up either consistency or availability.
In his 2012 retrospective, Brewer argued that the simple “pick two of three” slogan is misleading. Partitions are relatively rare, and when the network is healthy a system can offer both strong consistency and high availability. The real trade-off only bites during a partition, when a node that cannot reach its peers must either refuse the operation (preserving consistency) or proceed anyway (preserving availability).
This framing explains why many large-scale databases describe themselves as “CP” or “AP” systems. The choice is not made once and for all but is really a decision about how to behave during the relatively brief windows when the network is broken, and how to recover and reconcile state once it heals.