cap theorem
what picking two actually means when your network splits.
“pick two. they will then argue about which two.”
what picking two actually means when your network splits.
“pick two. they will then argue about which two.”
the CAP theorem says a distributed system can provide at most two of three guarantees: consistency, availability, and partition tolerance. this is often summarized as "pick two", which is technically accurate and practically misleading, because one of the three is not actually optional.
consistency (in the CAP sense) means every read receives the most recent write or an error. every node sees the same data at the same time. this is not "eventual consistency", it is the strong, linearizable kind. if you write a value, any subsequent read from any node returns that value.
availability means every request receives a response (not an error). the response might not contain the most recent data, but the system does not refuse to answer.
partition tolerance means the system continues operating when network messages between nodes are lost or delayed. some nodes cannot reach other nodes; the system keeps going.
here is why "pick two" is misleading: partition tolerance is not optional for distributed systems.
networks fail. messages get dropped, delayed, reordered. if you run more than one machine, a network partition is not a theoretical edge case, it is something that will happen, and you need to decide how your system behaves when it does.
so the real choice is: when a partition occurs, do you sacrifice consistency or availability?
a system that sacrifices consistency during a partition (CP) keeps responding but may return stale data. different nodes may disagree on what the current state is.
a system that sacrifices availability during a partition (CA) stops accepting requests rather than risk serving inconsistent data. it waits until the partition resolves and the nodes can agree again.
there is no distributed system that is both strongly consistent and fully available during a partition. the network does not cooperate.
most distributed databases land somewhere on the spectrum rather than at the extremes:
CP-leaning systems (like Zookeeper, HBase, traditional SQL clusters with synchronous replication) refuse writes or return errors when they cannot confirm the operation has been seen by enough nodes. during a partition, availability degrades. the data you get is always correct.
AP-leaning systems (like Cassandra, CouchDB, Riak) keep accepting reads and writes during a partition. each partition carries on independently. when the partition heals, the system reconciles the diverged state, usually via last-write-wins, vector clocks, or application-level conflict resolution.
"eventually consistent" means the system will converge to the same state across nodes, eventually, given no new updates. it is the consistency model you get in AP systems. it is not weak consistency in general; it is a specific contract: your read might be stale, but the system will not stay permanently inconsistent.
the catch is "eventually" is not bounded by default. how stale is stale? seconds? minutes? under partition, indefinitely? these questions have answers in specific systems, but "eventually consistent" on its own does not specify them. "eventually" on its own does not tell you whether that means seconds or minutes. check the specific system's guarantees.
the practical question is not which two you pick in the abstract. it is: what does your application actually need?
if your application requires that two users never see different values for the same data simultaneously, bank balances, inventory counts, seat reservations, you need consistency. you will accept that availability degrades during a partition.
if your application can tolerate stale reads, social media feeds, recommendation scores, user profile caches, you can choose availability. users see data that might be a few seconds old. that is an acceptable tradeoff.
the failure mode is choosing AP because "consistency sounds slow" without thinking through what happens when two nodes accept conflicting writes during a partition. conflict resolution is a real problem and most applications do not handle it gracefully by default.
CAP is a 2000-era result that simplifies a complex space. PACELC extends it: even when there is no partition (E), distributed systems trade latency for consistency. you pay a cost for consistency not just during failure but in steady-state operation as well.
understanding CAP gives you the vocabulary. understanding PACELC gives you a more complete picture of why the tradeoffs exist at all times, not only when things go wrong.