The CAP Theorem and Consistency Models, Explained Practically

Two datacenters, one replicated database, and the link between them fails. Users on both sides keep writing. The system now faces a forced choice: reject writes on one side and stay consistent, or accept writes on both sides and risk conflicting views of the data. It cannot do both. That inescapable choice (made specifically during a network partition) is the entire content of the CAP theorem. Properly understood, the CAP theorem is less a law of nature than an honest description of trade-offs a replicated system was already making.

The CAP theorem states that a distributed data system cannot simultaneously guarantee consistency (every read sees the latest write), availability (every non-failed node responds), and partition tolerance (operation despite network failures). Since partitions are unavoidable, the practical choice is between consistency and availability, and only while a partition lasts.

Where the theorem comes from

Eric Brewer introduced the conjecture in his 2000 PODC keynote on principles of distributed computing; Seth Gilbert and Nancy Lynch formalized it in 2002, proving that no distributed system can provide all three guarantees against an adversary that drops messages. The formalization matters because it also bounds what the theorem claims: it concerns reads and writes of a single, register-like object (not arbitrary transactions) and its “C” is linearizability, not the C of ACID. The theorem is narrow, true, and routinely over-applied.

What C, A, and P actually mean

Consistency, linearizability. Every operation behaves as if it executed atomically at one instant somewhere between its start and its finish, on a single copy of the data. If a write completes, every later read (from any node) sees that write or a later one. Linearizability says nothing about transactions spanning multiple objects; it is the illusion of one copy, one object at a time.

Availability. Every request to a non-failed node eventually returns a meaningful response: a successful read or write, not an error or an infinite hang. Notably, a response with stale data still counts as available.

Partition tolerance. The system continues to operate when messages between nodes are lost or arbitrarily delayed. Note the bar: a partition is any period when the network fails to deliver messages, full datacenter splits and slow links alike.

Why partition tolerance is not optional

The standard “pick two of three” framing misleads. P is not a feature you can decline: networks partition, and a system that does not tolerate partitions achieves that by becoming entirely unavailable during them, failing availability globally instead of gracefully. The design decision stated usefully is: when a partition happens, which guarantee do you sacrifice, consistency or availability?

CP and AP, concretely

• CP, sacrifice availability. The system refuses operations that would violate consistency. Coordination systems such as ZooKeeper and etcd work this way: a node that cannot reach a quorum of peers rejects writes. During a partition, the minority side is unavailable; after the partition heals, everything agrees, because nothing was accepted without a quorum.
• AP, sacrifice consistency. The system keeps accepting writes everywhere and reconciles later. DNS is the classic example: during any disconnection, every server keeps answering, and records converge as propagation completes. Dynamo-style key-value stores and many wide-column databases lean this way, exposing per-operation consistency settings instead of one global stance.

The same trade can surface inside one system: a database can run CP for one table (ledger entries via quorum writes) and AP for another (session data). “Is it CP or AP?” is a question about behavior during partitions, and increasingly, the answer is “you configure it per operation.”

The consistency-model ladder

“Strong vs eventual” is a dial with several positions, and each position is a different engineering object:

Reading the ladder from top to bottom: guarantees weaken, availability rises, and latency falls; each step trades agreement for responsiveness.

• Linearizability is the expensive end. To promise every reader the latest value, writes must coordinate: a quorum must agree before any node can promise the result. That coordination is exactly what distributed consensus builds; the algorithms (Raft, Paxos, ZAB) are compared in consensus algorithms.
• Eventual consistency is a liveness property, not a staleness bound. It promises convergence once writes stop, and nothing about how long convergence takes or what intermediate states look like. Replication lag (covered in database replication) is the real-world clock behind “eventual.”
• In between, causal consistency preserves the ordering humans notice (a reply never appears before its parent) without globally coordinating everything.

The engineering question is never “which model is best” but “which model does this particular data need?” A ledger and a like-counter legitimately live at different rungs.

PACELC: the trade-off that dominates normal operation

CAP’s choice only bites during partitions. Daniel Abadi’s PACELC extension (2012) adds the case that dominates everyday operation: if there is a Partition, choose Availability or Consistency: Else (no partition), choose between Latency and Consistency.

The reasoning: even on a perfectly healthy network, strong consistency costs latency. A write that must be seen by a quorum waits for at least one round trip to peers, often to another zone or region, tens to a few hundred milliseconds. A single-node write acknowledgment is microseconds. Systems that keep replicas synchronized pay that round trip on every write; systems that acknowledge locally risk stale reads. Most real “CAP decisions” are these latency-versus-consistency dials, set per operation rather than per system.

Choosing a stance, in practice

A workable decision sequence for any piece of shared data:

1. What breaks if two nodes briefly disagree? If the answer is “money moves twice,” “inventory oversells,” or “a lock is granted to two owners,” consistency must win for that data; take a CP stance with quorum writes or consensus. The costs: writes fail on the minority side of a partition, and every write pays coordination latency.
2. What breaks if a write is briefly rejected? If the answer is “a like doesn’t register” or “the feed is a second stale,” availability wins, take an AP stance with idempotency and conflict resolution. The costs: reconciliation logic, and temporary divergence you must reason about. This is precisely the availability-vs-reliability distinction in availability vs reliability vs durability.
3. Where do the replicas live? A synchronous cross-region write pays an inter-region round trip on every acknowledgment, often unacceptable for interactive traffic. Regional quorums with asynchronous cross-region replication (database replication) are the standard middle path: strong consistency within a region, eventual consistency across regions.
4. Who resolves conflicts? AP systems converge only if conflicts have a deterministic resolution; last-write-wins (which silently drops concurrent updates), version vectors, or convergent data types. Conflict resolution is the tax AP systems pay instead of coordination.

Two worked stances:

• A payment system takes CP on balances and ledger entries: reject the write, show the error, keep the books exactly right. Availability is sacrificed for the duration of the partition, by design.
• A social feed counter takes AP: accept every like everywhere, converge later, and never let a network blip make a button fail. If a count is briefly off, no money moves.

How CAP threads through the rest of system design

The theorem quietly underlies several topics in this library:

• Database replication; synchronous replication is the “C” side, asynchronous the “A” side; replication lag is the price of choosing A.
• Distributed consensus and consensus algorithms; the machinery that makes CP systems possible.
• Distributed caching; caches are aggressively AP: fast, eventually consistent with the source of truth, and correct only if staleness is bounded by design.
• Distributed transactions; two-phase commit is what strong consistency across services costs; sagas are the AP-flavored alternative.
• Fault-tolerant systems; surviving failures is the mechanism; CAP describes what surviving nodes may promise while others are unreachable.

Common misconceptions

• “CAP means pick two of three, always.” No. With no partition, a system can be both consistent and available, at latency cost. The choice is forced only during partitions, and PACELC is the honest everyday version of the trade.
• “Partition tolerance is a feature you can decline.” You can decline to handle partitions; you cannot decline to have them. Not handling them means total failure during every partition.
• “CAP consistency is ACID consistency.” Different C. ACID’s consistency means transactions preserve declared invariants: constraints, foreign keys. CAP’s consistency means linearizability of reads and writes on shared registers. A system can offer ACID transactions within each shard and still be AP across shards.
• “Eventual consistency means always stale.” It means convergence once writes stop, with no bound on how long. In healthy networks, replication lag typically makes staleness milliseconds to seconds; during a partition, it lasts exactly as long as the partition. The bound is an operational property, not a theorem.
• “Partitions are rare emergencies.” At the granularity that matters, partitions are routine: a node that pauses during garbage collection, a link that reroutes, a primary that fails over. Anything that delays messages between replicas is a partition to the consistency protocol.

FAQ

Why isn’t partition tolerance optional in CAP?

Because networks fail whether or not you design for it. A system that “rejects” P achieves consistency and availability only while the network is perfect, and loses both everywhere during any partition. Tolerating partitions is the precondition for being able to choose anything during one.

Is ZooKeeper CP or AP?

CP. ZooKeeper (like etcd and other consensus-based coordination systems) requires a quorum to agree on writes; a node cut off from the quorum stops serving writes rather than diverge. Distributed consensus explains the machinery that makes this work.

What does eventual consistency actually promise?

Only that replicas converge to the same value if updates stop arriving. It promises neither a staleness bound nor the absence of intermediate conflicts. Real systems bound staleness operationally, via replication-lag monitoring and read repair.

Does CAP apply to a single-node database?

No. The theorem concerns distributed systems whose replicas communicate over a network that can drop messages. A single node has trivial consistency and availability; its guarantees fail only with the machine; the failure-domain analysis is in availability vs reliability vs durability.

Can a system be consistent and available when there is no partition?

Yes; this is the normal state of a CP system with healthy quorums, and of an AP system with fast convergence. PACELC names the cost you still pay in this state: a latency-versus-consistency choice on every write.

Related articles

• Next read: what is a distributed system?; the environment that makes partitions unavoidable.
• database replication: the concrete knobs (synchronous, asynchronous, quorum) behind these stances.
• distributed consensus, how CP systems agree.
• availability vs reliability vs durability, the outcomes these trade-offs purchase.

Last updated on 10 September 2026