The CAP theorem — the trade-off you can't engineer around

A distributed system — one where data lives on more than one machine — can't simultaneously guarantee all three of:

The theorem's actual claim is narrower than it sounds: during an actual network partition, a system must choose between consistency and availability — it cannot provide both at that moment. Outside of a partition, when every node can talk to every other node, a system can be perfectly consistent and perfectly available at the same time; CAP only forces a choice in the specific, real situation where communication has broken.

In a system with more than one node, network partitions are a fact of life at scale, not a rare hypothetical — cables get cut, switches fail, cloud availability zones lose connectivity to each other. A system that simply refuses to handle partitions isn't making a valid CAP choice; it's a single-node system that hasn't been tested under real conditions yet. This is why CAP is usually framed as choosing between CP and AP specifically — P isn't a trade-off you opt out of, it's the premise the other two are being traded off under.

A CP system, when partitioned, refuses to answer from a node that can't confirm it has the latest data — it returns an error or times out rather than risk serving stale information. This is the right choice when returning wrong data is worse than returning no data: a banking system showing an incorrect account balance is a much bigger problem than a banking system being briefly unavailable. Traditional relational databases configured for strong consistency, and systems like ZooKeeper or etcd (used specifically for coordination, where correctness matters more than uptime), lean CP.

An AP system keeps answering even when partitioned, accepting that the answer might be stale until the partition heals and nodes can sync back up. This is the right choice when some answer, even a slightly outdated one, is more valuable than no answer at all: a social media feed showing a post that's a few seconds old is a far smaller problem than the feed simply not loading. DNS, and databases like Cassandra or DynamoDB (in their typical configuration), lean AP.

"Eventually consistent" is a precise, weaker guarantee than "always consistent" — it means that if no new writes occur, every node will eventually converge on the same value, but makes no promise about how long "eventually" takes, and gives no guarantee about what a read returns during that window:

This is a real, deliberate trade — not a bug or a temporary limitation waiting to be fixed. A system built on an eventually-consistent store has to be designed with the assumption that a read shortly after a write might not reflect that write yet, the same way the caching lesson's TTL-based invalidation accepts bounded staleness as the cost of a different benefit (there, speed; here, availability during a partition).

None of those earlier lessons used the word "CAP," but every one of them was making the same kind of choice this lesson names directly — favoring availability (or speed) and tolerating a bounded window of staleness, rather than blocking every operation until every node agrees.

CAP isn't a checklist to satisfy — it's a lens for a question that has to be answered honestly for any given piece of data: if this specific data is briefly stale during a partition, is that acceptable, or does it need to be rejected outright until consistency is restored? The answer is often different for different data in the same system: a checkout page's "is this item in stock" count might tolerate a few seconds of staleness (AP), while the same system's "did this payment actually go through" check should not (CP). Treating CAP as an all-or-nothing property of an entire system, rather than a decision made per piece of data, is the most common way this theorem gets misapplied in practice.