The CAP Theorem
Every distributed database makes a promise, and every distributed database eventually has to break part of that promise, on purpose, because the network made it break it. The CAP theorem is the formal statement of exactly which part gets broken and when. It sounds abstract until you see the actual moment it applies — a cable gets cut, two data centers can't talk to each other, and every system behind that cable has to 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 is the actual argument for why you can't have all three, walked through with a concrete network partition. Phase 3 grounds it in real databases you've probably used, and clears up the most common misreading of the theorem.
The phases
- The three letters — consistency, availability, and partition tolerance, defined precisely.
- Why you can't have all three — walking through a real partition and the forced choice it creates.
- What this looks like in real databases — CP systems, AP systems, and the most common misreading of CAP.