CAP Theorem

How it works

In a distributed system, you can only guarantee two of Consistency, Availability, and Partition tolerance at once. Networks fail, so partition tolerance isn't really optional — the real choice happens during a partition: block/error to stay consistent (CP), or keep answering with data that might be stale (AP).

Mental models

• Partition tolerance isn't optional — networks fail, so you're really choosing between C and A when they do.
• CP blocks or errors during a partition rather than risk returning stale data — good for atomic reads and writes.
• AP keeps answering during a partition, possibly with stale data — good when eventual consistency is acceptable.
• CAP only describes behavior during a partition — most of the time, with no partition, you get both C and A.
• NoSQL's BASE model (basically available, soft state, eventually consistent) is the AP side of this tradeoff; RDBMS transactions lean CP.

Common pitfalls

• CAP is binary in theory but real systems tune consistency per-operation, not system-wide.
• Choosing AP doesn't mean 'no consistency' — eventual consistency still needs a conflict-resolution strategy for when replicas disagree.
• Latency and consistency trade off even without a partition (see PACELC) — CAP alone doesn't describe normal-operation behavior.