The CAP Theorem

Every distributed database makes a promise, and eventually breaks part of it - on purpose, because the network forced it to. The CAP theorem is the formal statement of which part breaks, and when. It sounds abstract until the actual moment it applies: a cable gets cut, two data centers can't talk, and every system behind that cable must decide, right now, whether to keep answering or keep agreeing - it can't do both.

How to read this

Read it in order. Phase 1 defines the three letters precisely - most confusion about CAP comes from vague definitions of "consistency" and "availability." Phase 2 walks through the actual argument for why you can't have all three, using a concrete network partition, and Phase 3 grounds it in real databases you've probably used and clears up the most common misreading of the theorem.

The phases

1. The three letters - consistency, availability, and partition tolerance, defined precisely.
2. Why you can't have all three - walking through a real partition and the forced choice it creates.
3. What this looks like in real databases - CP systems, AP systems, and the most common misreading of CAP.