The CAP Theorem

Distributed Systems Fundamentals established that the network can drop messages. The CAP theorem, formalized by Eric Brewer, is the precise statement of what a distributed data store has to give up when that happens.

The three properties, defined precisely#

• Consistency — every read receives the most recent write, or an error. This is a stronger guarantee than ACID's "C," closer to what the literature calls linearizability: every client sees the same value at the same logical moment, regardless of which node answers.
• Availability — every request to a non-failing node receives a response — not necessarily the most recent value, just a response, rather than a timeout or an error.
• Partition tolerance — the system keeps operating even when network messages between nodes are delayed or dropped.

"Pick two" is not quite what the theorem says#

The popular shorthand — pick two of C, A, P — is misleading because P is not really optional. Real networks partition: a switch fails, a link saturates, a data-center link drops. A system that claims to sacrifice partition tolerance is really just a system that has not yet experienced a partition. The actual choice CAP describes is narrower and sharper: when a partition happens, does the system choose consistency or availability for the duration of that partition?

Node A -------- X -------- Node B(partitioned: A and B cannot talk to each other)
A write arrives at Node A. Node A must choose:
  CP: refuse the write (or the read) until the partition heals —      consistent, but unavailable to this client right now.
  AP: accept the write locally anyway —      available, but now A and B disagree until they reconcile.

Every real system's answer is a specific engineering decision, not a label chosen once and applied everywhere: the same database can behave CP for one operation and AP for another, depending on configuration.

PACELC: the trade-off that exists even without a partition#

CAP only describes behavior during a partition. PACELC extends it with the trade-off that exists the rest of the time: if Partitioned, choose Availability or Consistency; Else, choose Latency or Consistency. Even on a perfectly healthy network, a system that wants every replica to agree before acknowledging a write pays for it in latency — waiting for that agreement takes real time. A system that acknowledges immediately and replicates afterward is faster, at the cost of a brief window where a read from a different replica can return a stale value.

Where this shows up in systems already covered on this site#

Topics, Partitions, and Offsets covers Kafka's acks setting — how many in-sync replicas must confirm a write before the producer considers it successful. acks=all leans toward consistency at the cost of latency; acks=1 leans the other way. That single setting is a PACELC decision made concrete, in a system already covered elsewhere on this site as a practical tool rather than a theory.

Common mistakes#

Treating "CP" or "AP" as a fixed, permanent label for a whole system#

Most real databases let this trade-off be tuned per operation, per table, or per query — a single fixed label oversimplifies what the system actually offers, and doesn't answer the PACELC question CAP is silent on.

Concluding CAP means "consistency is impossible in distributed systems"#

CAP describes a trade-off during a network partition specifically, not a blanket impossibility. Plenty of distributed systems provide strong consistency the overwhelming majority of the time — CAP just describes what has to give during the (hopefully rare) moments the network is actually partitioned.

Confusing CAP's Consistency with ACID's Consistency#

Reading a database's claim to be "consistent" without checking which definition it means — cross-node agreement, or transactional validity — is a fast way to misunderstand what it actually guarantees.

Further reading#

• CAP theorem — the formal statement and its history.
• CAP Twelve Years Later: How the "Rules" Have Changed — Brewer's own retrospective, addressing common misreadings of the original theorem.
• PACELC design principle — the extension covering the non-partition case.
• Topics, Partitions, and Offsets — a concrete acks setting that puts this trade-off into practice.

See also#