CAP, PACELC, and Consistency Models: Choosing the Right Contract

Why Replication Forces a Consistency Choice

Replication removes a single point of failure, but it also creates a decision you cannot avoid: what should a replica do when it cannot reach the other replicas? The network can drop packets, switches can fail, and a cross-datacenter link can disappear during maintenance. A partition is a network failure that splits the system into two or more isolated groups. Once that happens, the replicas cannot establish a shared view of the latest value.

You have two operationally meaningful choices. Keep serving from each reachable replica, and some clients may read stale data or write values that other replicas have not seen. Or stop operations that require agreement until communication returns, protecting the data at the cost of failed or delayed requests. Neither choice repairs the network; each chooses which failure your users experience.

Consider a DynamoDB-style leaderless cluster replicated across two datacenters. A link failure isolates the datacenters, but clients in both halves can still reach local replicas. If both halves accept a write to the same key, each can acknowledge a different version. When the link heals, the cluster has to reconcile those conflicting versions; if both segments continue to accept writes without coordinating, they create divergent histories of the data. The system stayed responsive during the split, but the application now needs a conflict-resolution rule and must tolerate the possibility that a read was not globally current.

That is why CAP is useful as an operational question but misleading as a menu of three freely selectable options. In a partitioned, replicated system, partition tolerance is imposed by the environment; the design decision is which consequence to accept when replicas cannot coordinate. CAP's job is to make that availability-versus-divergence decision explicit.

CAP Precisely: Consistency Versus Availability During a Partition

CAP becomes concrete when two replicas hold the same key and can no longer communicate. You then have two incompatible request paths. A consistency-first path waits until it can coordinate with the required replica set; if coordination is impossible, it refuses the operation. An availability-first path responds from the reachable replica, even though another replica may accept a different write. The choice is not whether the partition exists. It is whether this operation preserves a single globally current value or keeps answering while versions diverge.

What C and A mean in CAP

The C in CAP is stronger than “the replicas usually catch up.” It means linearizability: after a successful write, every subsequent read anywhere in the system sees that write. A read cannot legally return the older value merely because it reached a replica that has not caught up. To preserve that guarantee during a partition, the system must prevent an isolated side from acknowledging a write or serving a read it cannot establish as current.

The A in CAP is also stronger than “the service is up.” Every request sent to a non-failed node must receive a response, even when that node cannot reach its peers. Returning an error to avoid conflicting writes preserves consistency, but it is not CAP availability. A system that serves only the connected half, or that fails writes while continuing reads, may provide useful partial behavior, but you must evaluate availability per operation and per node rather than label the whole deployment “available.”

The two choices are straightforward under a partition: a consistency-first path waits for coordination and refuses the operation if coordination is unavailable; an availability-first path serves from a reachable replica and accepts that versions may diverge. This describes the trade-off, not a prescribed partition-detection algorithm.

CP, AP, and the tunable middle

An HBase-style CP choice refuses writes to an affected region during a partition rather than risk two sides accepting incompatible values. A Cassandra-style AP choice accepts writes on any available replica and reconciles them later. In the latter case, a partition between two datacenters can produce one version in each half for the same key. Healing the network restores communication, not an automatic answer about which business value was correct; reconciliation must merge or select among those versions.

Real databases also expose consistency as an operation-level setting instead of a permanent system-wide label. A quorum read consults enough replicas to obtain a stronger view than a ONE read, which consults only one replica; the stronger choice requires more coordination and can lose availability when the required replicas are isolated. The exact dial is a design decision: choose the weakest read and write guarantees that still protect the invariant for that operation. The same service can keep a conflict-tolerant read path available while requiring stronger coordination for a purchase or other correctness-critical write.

PACELC: The Trade-Off You Pay on Healthy Days

CAP describes the exceptional path: what the system does while replicas cannot communicate. PACELC adds the path you execute on ordinary requests: if there is a Partition, choose between Availability and Consistency; Else, when the system is healthy, choose between Latency and Consistency. CAP is silent about the normal-case latency–consistency trade-off, not just behavior during a partition.

Two normal-operation read paths

A strongly consistent read cannot simply ask whichever replica is closest and return its answer. The system must coordinate: redirect the request to a leader, wait for quorum participation, or perform a repair that verifies and reconciles the value before returning it. That coordination establishes that the returned value includes the latest successful write, but each extra network hop or acknowledgement adds latency.

An eventually consistent read takes the opposite path. The coordinator sends the request to a nearby replica and returns that replica's local value without waiting for the other replicas. The request finishes sooner, but the value may be stale because an earlier write has not reached this replica yet. You have exchanged a stronger read guarantee for lower latency; the stale-value window is part of the contract, not an accidental implementation detail.

This is the normal-case meaning of PACELC's EL branch. A system that favors consistency pays coordination latency even when every node is healthy. A system that favors latency reduces coordination and accepts weaker read observations. The trade-off is not simply “fast versus slow”: it is whether the caller can tolerate a response that may lag behind a completed write.

The shorthand makes that decision visible. DynamoDB is commonly described as PA/EL: it favors availability during a partition and low latency otherwise. Spanner and CockroachDB are described as PC/EC: they favor consistency during a partition and in normal operation, paying the coordination cost required to preserve that contract. The labels summarize a tendency, not a single setting that determines every operation.

The Consistency Spectrum Is a Contract, Not a Label

A consistency model is a formal contract between a storage system and its callers: for each read, it specifies which writes the result must include and which order the caller is allowed to observe. That makes consistency a property of an operation history, not a label attached to an entire database. A single system may expose stronger or weaker guarantees for different operations, but each operation still needs a precise contract.

Four contracts, four observable histories

The spectrum is easiest to use when you ask what histories a client is allowed to observe. Linearizability is the strongest model here. Linearizability requires every read to reflect the most recent write, and operations appear globally ordered according to that recency guarantee. After a successful write completes, a later read sees that write or a newer one. The system must coordinate replicas on each operation, which makes the contract expensive, but the resulting behavior is simple to reason about.

Sequential consistency keeps one common order of operations for all processes, but that order does not have to match wall-clock order. Two clients therefore cannot disagree about whether write A preceded write B in the observed history, even if the system places those writes in an order that differs from when they completed. This is a real relaxation from linearizability: the common history is preserved, but recency across replicas is not.

Causal consistency preserves only relationships that could have influenced one another. If one operation causally causes another, every node must expose the earlier operation before the causally dependent operation. Concurrent writes have no required order, so different clients may observe them in different sequences. CRDTs and vector clocks are mechanisms used to represent or preserve this kind of relationship; they do not make concurrent operations globally ordered.

The artifact makes that distinction operational. Client A's read of x establishes the dependency before its write to z; therefore R2 cannot return z while hiding x. Client B's write to y is concurrent, so R1 may read x then y while R2 reads y then x. The important boundary is not whether replicas eventually contain both values, but which order each caller is permitted to see while replication is still in flight.

Eventual consistency removes ordering guarantees altogether. If writes stop, replicas converge to the same value, but clients can read different or older values for an unbounded period; convergence is guaranteed if writes stop, but no deadline is guaranteed. Azure Cosmos DB describes the practical failure mode directly: “This replica could be lagging and could return stale or no data.” The application must supply the missing conflict policy, such as last-write-wins or a CRDT merge function, and must remain correct while replicas disagree.

Use the model as a design constraint. A seat reservation needs a single defensible order for competing claims on the last seat; an eventually consistent history can expose both reservations before reconciliation. A shopping cart can instead merge independent additions, because the application can preserve both operations. The next design question is therefore not “which database is strong?” but “which histories can this subsystem safely expose, and what does it do when the contract permits disagreement?”

Worked Example: A Cart Can Merge; the Last Seat Cannot

Choose the consistency model by pricing the worst plausible mistake. If a stale value can lose money, sell the same inventory twice, or violate a uniqueness rule, you need a stronger guarantee. If the value is cosmetic or recoverable, you can often trade strictness for lower latency and higher availability. A globally distributed shopping cart sits closer to the second category; a payment authorization and a seat reservation sit firmly in the first.

A cart can merge concurrent intent

Assume two replicas receive concurrent additions while the network link between them is unavailable. Replica R1 records add(item A), while replica R2 records add(item B). Neither operation overwrites the other: each replica has one addition, and the CRDT merge preserves both independent additions. After reconciliation, the cart contains item A and item B: 1 addition + 1 addition = 2 surviving additions. Both writes win because they express independent intent, and the merge function can preserve both.

That is a good fit for write-heavy, latency-sensitive global data. A user can tolerate a feed that is 200 ms = 0.2 seconds behind, or a cart that temporarily displays a duplicate item and can be repaired or merged by the application. The consequence is recoverable: the application can remove a duplicate or refresh the cart. The model is causal or eventual, depending on the guarantees you require; either way, the conflict-resolution strategy is part of the design rather than an afterthought.

The last seat cannot merge

Now apply the same partition to a venue with 1 available seat. Client A reaches replica R1 and reserves it. Client B reaches replica R2 and also reserves it before either replica sees the other's write. If both requests succeed, the arithmetic is 2 successful reservations − 1 available seat = 1 excess reservation. Reconciliation cannot make both reservations true: the system must reject one, compensate one, or discover the conflict after it has already promised the seat.

The reservation therefore needs linearizability, or at minimum a serializable transaction: concurrent claims for the unique resource must be ordered so only one can consume the final seat. The same reasoning applies to payments, inventory, and usernames. Strong consistency is not required everywhere in the product; it is required at the boundary where a stale or conflicting value creates an irreversible business error. One system can consequently use strong consistency for its ledger, eventual consistency for its activity feed, and causal consistency for collaborative document edits.

Choosing the Model by Failure Cost and Read Latency

Start with the failure cost, not the database label: what is the worst thing that can happen if a caller sees a stale or conflicting value? If the answer involves money, inventory, safety, or a uniqueness constraint, a wrong answer costs more than a slower one. Choose linearizable reads or, at minimum, serializable transactions, and make coordination part of the latency budget. For cosmetic, recoverable, or high-volume data, serving a nearby replica and resolving conflicts later is often the better trade.

The comparison below separates two concerns engineers often collapse into one: what ordering or freshness callers receive, and what the system must pay to provide it. A model is not just a guarantee; it also determines whether reads coordinate, whether stale values are visible, and where conflict-handling logic belongs.

The important boundary is not “strong versus weak” in the abstract. It is whether the application can recover when two valid-looking answers exist. A shopping cart can merge two concurrent additions; a social feed can show a post that is not the newest post; view counts can converge after replicas catch up. Those workloads are write-heavy, latency-sensitive, and globally distributed, so eventual or causal consistency is reasonable only when the conflict-resolution strategy is designed into the data model.

Money, inventory, and unique names invert the decision. A payment authorization cannot quietly merge two conflicting outcomes, two reservations cannot both consume the last seat, and two users cannot both win a uniqueness check. Route these operations through linearizable coordination or serializable transactions and accept the added latency. The price is paid on the path where correctness matters, rather than later through reconciliation and customer-visible repair.

PACELC is useful in a design review because CAP describes behavior during a partition, while PACELC also forces you to name the normal-case price. A PA/EL design favors availability and low latency; a PC/EC design favors consistency and pays through coordination. For every subsystem, record the failure cost of stale data, the conflict-resolution rule, and the latency the caller can tolerate. That turns “eventual consistency” from a vague aspiration into an explicit contract.

Failure Mode: Availability Creates Conflicts You Must Reconcile

The failure sequence

An AP system fails in a specific sequence, not in a single dramatic event. A DynamoDB-style leaderless cluster is split between two datacenters. Each replica group can still reach its local clients but cannot reach the other group, so both halves accept a write for the same key. The first group records one version; the second records a concurrent version. Neither side can establish a single latest value while the link is down.

When the partition heals, connectivity returns before the data is necessarily reconciled. Replicas exchange versions or invoke a merge rule, but the system must now resolve the divergence created while both sides were available. Cassandra exhibits this behavior: it is AP by default, accepts writes on any replica, and reconciles later. The operator may see conflict-resolution work increase after recovery, while clients can observe different values depending on which replica answers.

That window is the practical meaning of eventual consistency. Replicas converge to the same value if writes stop, but before convergence different clients may see different values. There is no timing guarantee for when convergence completes. A retry, a read from another replica, or a request routed to a different datacenter can therefore expose an older value or a conflicting value even though the partition has already ended.

The defence is to make conflict handling part of the data contract before choosing availability. For replaceable metadata, last-write-wins may be sufficient if losing one concurrent update is acceptable. For additive operations such as independent cart additions, use a CRDT or another merge function that preserves both updates. For values whose conflicts cannot be repaired safely—such as a balance, inventory count, or unique reservation—route the operation through a consistency level that coordinates replicas, or reject it while the required quorum is unavailable.

Do not classify the entire database from its partition behavior alone. Cassandra exposes a consistency dial per operation. A ONE read consults one replica and favors availability; a QUORUM read consults a quorum and moves toward a stronger view, paying additional coordination latency. Outside a partition, quorum reads can provide very strong consistency guarantees even though Cassandra remains AP by default. The trade is operational: stronger reads and writes increase coordination and reduce the set of failures the operation can tolerate, while weaker operations leave more reconciliation work for the application.

Failure Mode: A Weak Contract Becomes a Business Bug

The dangerous version of eventual consistency is not “briefly wrong.” It has no timing guarantee. If replication is delayed, a client can continue reading an old balance for seconds, minutes, or until the next anti-entropy cycle. Azure Cosmos DB’s documentation puts the operational symptom plainly: “This replica could be lagging and could return stale or no data.” A dashboard may show healthy request success rates while an important read is using state that is arbitrarily old.

That becomes a business bug when the read participates in a decision. Suppose a customer has one available unit of inventory. The checkout service reads an old replica showing one unit, while another checkout has already committed the purchase elsewhere. If both authorizations proceed from that stale value, the system sells the same unit twice. A bank ledger has the analogous failure: a stale balance read can approve a payment that causes an overdraft. The fix is not merely to reconcile replicas later; reconciliation cannot undo a payment already authorized or inventory already promised.

Do not confuse serializability with linearizability. Serializability constrains the outcome of a transaction containing multiple operations: it must behave as if those transactions ran one at a time. Linearizability constrains the recency of an individual operation across replicas: after a successful write, a later read must reflect it. A system can isolate transactions correctly while a separate read path returns an older replica value, or provide current single-key reads without making a multi-step transaction atomic. Your payment authorization needs both properties that its workflow depends on, not a vague label such as “strong.”

For high-cost state, make the contract explicit: use linearizable reads or, at minimum, serializable transactions, and accept the coordination latency they require. For lower-cost state, eventual or causal consistency can be correct only when the application has an explicit merge or conflict policy and can tolerate unbounded staleness. A write-always, merge-on-read shopping cart may be suitable for cart state, but it must not be the authority for checkout payment processing. Separate the recoverable view from the authoritative decision, and enforce the stronger guarantee at the decision boundary.

Defending a Consistency Choice in a Design Review

In a design review, start with the consequence rather than the database label: what is the worst-case cost of showing a stale or conflicting value? If the answer involves money, safety, inventory, or a unique constraint, require a contract that prevents conflicting decisions, and accept coordination, retries, or errors during a partition. If the result is cosmetic or recoverable, weaker consistency may be the better choice—but only after you name how conflicts merge and how much staleness the caller can tolerate.

The questions that expose a vague requirement

When someone says, “the user profile service only needs eventual consistency,” split the profile into fields and failure cases. Which fields may be stale? Could an old value affect authorization, billing, inventory, or uniqueness? Can two replicas update the same field concurrently, and what conflict-resolution rule applies? Does the caller need a staleness bound, or is unbounded convergence acceptable? “Eventually” is not a short, fixed delay; without an additional bound, the contract does not promise when replicas converge.

The grid gives you a compact way to make that reasoning explicit. Notice that a profile is not automatically a weak-consistency problem: a display name can usually converge later, while an authorization field may need a stronger path. A cart can merge concurrent adds, but checkout and payment must not inherit the cart’s relaxed contract. For a ledger or the last seat, the business consequence—an incorrect balance, duplicate charge, or oversell—justifies serialization and the latency it costs.

A strong answer names four things: what happens during a partition, what coordination costs in the healthy path, what reads can visibly return, and what business failure follows. CAP is not a free CA/CP/AP menu: partition tolerance is an environmental condition in a multi-node deployment, so the decision is what you sacrifice when the partition occurs. PACELC adds the normal case: even without a partition, favoring lower latency can mean reading without coordination and exposing stale data. An answer that says “AP means no consistency” is also incomplete; it describes the partition behavior, not every guarantee the system can provide during healthy operation or through stronger per-operation reads.