CAP Theorem

What is it: In a distributed system, during a network partition, you must choose between Consistency and Availability. Partition Tolerance is non-optional (networks partition; you cannot assume otherwise).

Consistency (C): every read receives the most recent write, or an error. All nodes have the same view.

Availability (A): every request receives a response (not necessarily the most recent data). No errors, no timeouts.

Why you cannot have both during a partition: If two nodes are partitioned (cannot communicate) and you require consistency — the node that did not receive the latest write must either reject the read (sacrificing availability) or return stale data (sacrificing consistency). There is no third option.

graph TD w["Write: balance = 100"] --> n1["Node A (has the write)"] n1 -.->|"network partition — cannot communicate"| n2["Node B (never received it)"] r["Read request lands on Node B"] --> n2 n2 --> cp["CP choice: reject the read<br/>(unavailable, but never wrong)"] n2 --> ap["AP choice: return the OLD value<br/>(available, but stale)"]

CP systems: ZooKeeper, etcd, HBase, Redis Cluster. During a partition, they refuse requests rather than return stale data. Correct for: configuration management, distributed locks, leader election — where stale data causes bugs.

AP systems: Cassandra, DynamoDB, CouchDB. During a partition, they continue serving requests, potentially returning stale data. Correct for: user profiles, product catalog, activity feeds — where availability matters more than having the absolute latest value.

What NoSQL sacrifices: NoSQL databases (Cassandra, DynamoDB) sacrifice strong consistency. A write to one node may not be immediately visible on another node. They implement eventual consistency: given no new writes and enough time, all nodes converge to the same value. They trade the C in ACID for the A in BASE.

Real-world usage: Proxel's proxy score system uses Redis (AP for this use case): scores may be slightly stale across processes during a Redis partition, but availability is prioritized — workers must not stop because they cannot read a score.

Common pitfall

CAP only describes behavior during an actual network partition — outside of one, most CP and AP systems both give consistent, available reads, because there's nothing forcing the trade-off. Calling a system "CP" or "AP" as a permanent label obscures that this is a choice made specifically for the rare moment of partition, not a description of its everyday behavior. It's also easy to conflate CAP's "Consistency" with ACID's "Consistency" — they're different, unrelated definitions that happen to share a word: CAP's C means "every read sees the latest write," ACID's C means "the database never violates its declared invariants."