The CAP theorem says that when a network partition happens in a distributed data store, you must choose between Consistency and Availability. Either some requests are refused until the partition heals (stay consistent), or every node keeps answering but some answers may be out of date (stay available). You can't have both during the partition.
In simple words
Two bank branches share one account book over a phone line, and the line goes dead. Either a branch refuses transactions until the line is back (consistent but unavailable), or both keep serving and risk disagreeing about the balance (available but inconsistent). You can't have both while the line is down.
Node 2 can't hear node 1. Refuse Y (consistent) or answer with stale data (available).
The Three Letters
C — Consistency (linearizability): every read sees the most recent write, as if there were one copy of the data.
A — Availability: every request to a non-failed node gets a (non-error) response.
P — Partition tolerance: the system keeps working even when messages between nodes are lost or delayed.
Networks do partition (a switch fails, a region link drops), so P isn't optional for a distributed system. The real choice is CP or AP during a partition. "CA" only describes a single-node system.
How It Plays Out
Two replicas, the link between them breaks:
client X -> [ node 1 ] X~~~~~X [ node 2 ] <- client Y
balance=100 balance=100
X withdraws 80 via node 1; node 1 can't tell node 2.
CP choice: node 2 refuses reads/writes on that data until it can reach
node 1 (or a quorum) -> correct, but Y gets errors
AP choice: node 2 answers "balance=100" and may accept its own writes
-> Y is served, but sees stale data; conflicts reconciled later
Which to Choose
CP for data where a wrong answer is worse than no answer: payments, inventory counts, seat booking, leader election, unique usernames. Systems: etcd, ZooKeeper, Spanner, most single-leader SQL setups with synchronous failover.
AP for data where staying up matters more than being perfectly current: social feeds, likes, product catalogs, shopping carts (merged later). Systems: Cassandra, DynamoDB-style stores in their default modes, DNS.
The choice is per operation, not per company. One system can use a CP store for orders and an AP store for recommendations.
PACELC: The Part CAP Leaves Out
Partitions are rare; latency is constant. PACELC extends CAP: if Partition, choose A or C; Else, choose Latency or Consistency. Even with a healthy network, waiting for replicas to agree (consistency) costs latency. Dynamo-style stores are PA/EL; Spanner-like systems are PC/EC.
Key Pointers
During a partition: consistency or availability. Not "pick two of three".
Consistency in CAP means linearizability, not the "C" in ACID.
Choose per data type: money and uniqueness lean CP; feeds and counters lean AP.
Many stores let you tune per request (quorum reads/writes, consistency levels).
Follow-up Questions
Is a single Postgres server CA?
It's not distributed, so partitions between replicas don't arise; CAP is about replicated systems. Once you add replicas and failover, you're choosing: synchronous replication with fenced failover leans CP; reading from async replicas accepts staleness.
Can Cassandra be consistent?
Per request, yes: with quorum writes and quorum reads (W + R > N) a read overlaps the latest write in normal operation, at the cost of latency and of availability when too many replicas are unreachable.