CAP Theorem & Consistency Models
Why a distributed system can't have perfect consistency, availability, and partition tolerance all at once — and what real systems trade off.
The theorem
In the presence of a network partition (P) — which any distributed system must eventually tolerate — you can only pick one of: Consistency (every read gets the most recent write) or Availability (every request gets a response, not an error, even if it might be stale). You can't have both during a partition.
What this means in practice
"CA" (consistent and available, no partition tolerance) isn't a real option for a distributed system — partitions happen. The real choice is between CP systems (refuse requests rather than risk stale/inconsistent data during a partition — e.g. many traditional relational setups) and AP systems (keep responding, accept that some responses may be stale until the partition heals — e.g. DNS, many NoSQL stores).
Consistency isn't binary
Beyond the CAP theorem's strict "consistency," real systems offer a spectrum: strong consistency (reads always see the latest write), eventual consistency (reads may be stale but will converge given enough time without new writes), and points in between like read-your-own-writes.
Prerequisite
Builds directly on database scaling — replication is exactly the mechanism that forces this consistency-vs-availability choice.