CAP, PACELC, and Consistency Models: Choosing the Right Contract
A practical guide to choosing consistency guarantees by failure cost and latency budget. It explains what CAP means during a partition, how PACELC exposes the normal-case latency–consistency trade-off, how linearizability, sequential, causal, and eventual consistency differ in observable histories, and why carts and feeds can tolerate weaker contracts while ledgers, inventory, and reservations cannot.
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.
Design a platform-scale distributed rate limiter55 min
Critique: find the failure modes in a given design45 min
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.
A leaderless cluster can remain available on both sides of a datacenter split, but reconciliation must resolve the divergent versions afterward.
Trace the two datacenter lanes from the failed link through independent writes to the conflicting versions exchanged after the link heals.
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.
The same replicated key produces different acknowledgement outcomes when peer coordination is unavailable.
Compare the acknowledgement on each side: the CP path returns an error without peer coordination, while the AP path accepts both writes and leaves divergent versions to reconcile.
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.
CHECK YOUR UNDERSTANDING
Why does a multi-replica system need coordination for a linearizable read, and what can an eventually consistent read skip?
SHOW ANSWERHIDE ANSWER
A linearizable read must establish that no newer successful write exists on another replica before it returns a value. It therefore coordinates with the relevant replicas, or routes through a single authority that can make that determination. An eventually consistent read can return the value from one reachable replica immediately, accepting that the replica may be stale and that different clients may temporarily read different values.
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.
Normal-operation reads trade coordination latency for a stronger freshness guarantee.
Compare the coordinated lane, which waits for confirmation before returning the latest value, with the nearest-replica lane, which returns earlier while the stale-value window is still open.
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.
CHECK YOUR UNDERSTANDING
How does PACELC expose a trade-off that CAP is silent about? Give a concrete example of a system that sits at PC/EC and explain what it pays to be there.
SHOW ANSWERHIDE ANSWER
CAP describes the consistency-versus-availability choice during a partition. PACELC adds that, when no partition exists, consistency still competes with latency. Spanner or CockroachDB is a PC/EC example: it preserves a strong consistency contract during partitions and during normal operation, and pays higher read and write latency for the coordination needed to do so.
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.
Each row preserves fewer constraints on the same distributed history, moving from real-time global order to convergence without ordering.
Compare the same writes and reads across the four rows: each weaker model removes one ordering or convergence guarantee that the stronger row preserves.
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?”
CHECK YOUR UNDERSTANDING
A client observes a write to x and then writes z. Another client concurrently writes y. Under causal consistency, which orderings are forbidden, and which can differ between replicas?
SHOW ANSWERHIDE ANSWER
A replica cannot expose z without first exposing the causally prior write to x. The concurrent writes to x and y may be observed in different orders by different replicas; causal consistency does not impose a global order on concurrent operations.
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.
CHECK YOUR UNDERSTANDING
Why is a shopping cart a good candidate for a CRDT-based eventual-consistency model, but a payment authorization is not?
SHOW ANSWERHIDE ANSWER
A cart can merge independent additions: two concurrent add operations can both survive reconciliation, and a duplicate or stale display is recoverable. A payment authorization represents money and cannot be safely merged when two replicas make conflicting decisions. It needs a strong ordering or serializable transaction so the system does not approve an invalid or duplicate charge.
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.
Use the cost of stale or conflicting data to choose the guarantee and the coordination you can afford.
Model or PACELC choice
Ordering/recency guarantee
Coordination and latency price
Appropriate subsystem
Linearizable / PC/EC
Linearizable; reads reflect the latest write
Higher; quorum coordination
Financial data, inventory, locks
Causal
Causally related operations preserve order; concurrent operations may appear in different orders
Causal tracking and conflict handling; weaker ordering guarantees than linearizability
Collaborative document edits
Eventual / PA/EL
Replicas converge eventually; clients may read stale values and concurrent writes may conflict
Lower coordination cost; reads can use a single replica and may return stale values
Shopping carts, social feeds, sessions, analytics
Serializable transactions
Transactions appear as if executed one at a time; single-operation recency is a separate guarantee
Transaction coordination and latency; prevents conflicting updates
Payments, seat booking, usernames
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.
CHECK YOUR UNDERSTANDING
A product profile can tolerate a stale avatar, but a username cannot be duplicated. Should both fields use the same consistency model?
SHOW ANSWERHIDE ANSWER
No. The avatar can use eventual or causal consistency with conflict handling because the error is cosmetic and recoverable. The username requires linearizable coordination or a serializable uniqueness check because a conflicting value creates a correctness and identity bug.
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.
Availability during isolation creates divergent versions that remain observable until reconciliation converges the replicas.
Follow the two isolated replica groups from their divergent writes through healing and version exchange; the separate pre-convergence reads are the important failure window.
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.
CHECK YOUR UNDERSTANDING
A leaderless database accepts writes on any replica. During a network partition between two datacenters, both sides accept writes to the same key. When the partition heals, how does the system decide which value wins, and what consistency model does that imply?
SHOW ANSWERHIDE ANSWER
The replicas exchange the divergent versions and apply the configured conflict rule—such as last-write-wins, a CRDT merge, or application-level logic. Until that process converges, different clients may read different values. This is eventual consistency during the available partition path: the system remains available and reconciles later, but it does not guarantee one globally ordered result for every read.
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.
A stale read can be individually valid yet still authorize a payment against a balance that has already changed.
Follow the shared timeline from the committed balance update to the stale read, then to the authorization that creates the overdraft path.
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.
Use the worst consequence of stale or conflicting data to choose a minimum contract, then defend any weaker guarantee with an explicit recovery or merge strategy.
Subsystem
Worst-case stale/conflict cost
Minimum suitable consistency contract
Follow-up or defense
User profiles
Usually recoverable; higher if a stale field affects authorization, billing, inventory, or a unique constraint
Eventual or causal, with conflict resolution
Which fields may be stale? What staleness bound does the caller require? Can a conflict affect authorization, billing, inventory, or uniqueness?
Shopping carts
Duplicate or lost item updates; usually recoverable before checkout
Eventual or causal, with merge-on-read or CRDT conflict resolution
Can concurrent adds both win? How are duplicates merged? Keep checkout and payment on a stronger contract.
Social/activity feeds
A user may miss or briefly see an old activity item; low correctness cost
PA/EL-style eventual consistency
Is a post from a short time ago acceptable? Prefer low latency when staleness is invisible and recoverable.
Ledgers or payments
Incorrect balance, duplicate charge, or financial loss
Linearizable or serializable transactions
Which operation is the source of truth? Accept coordination and higher latency rather than showing a stale balance or authorizing twice.
Inventory or seat booking
Overselling inventory or reserving the same last seat twice
Linearizable or serializable transactions
Must concurrent reservations be serialized? If a stale read can create an oversell, reject or retry rather than serve it.
Collaborative edits
Conflicting edits can overwrite work or produce an invalid document
Causal or eventual consistency with CRDTs or vector clocks
Which edits are causally related? Define the merge function and verify that concurrent operations commute or remain recoverable.
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.
CHECK YOUR UNDERSTANDING
A product manager says that a user profile service only needs eventual consistency. What must you ask before accepting that choice?
SHOW ANSWERHIDE ANSWER
Ask which fields may be stale, whether stale or conflicting values can affect authorization, billing, inventory, or a unique constraint, what conflict-resolution strategy applies, and whether the caller requires a staleness bound. Then separate harmless display data from fields that can make a business decision.
KEY TAKEAWAYS
CAP describes the consistency-versus-availability choice when a partition prevents replica coordination; partition tolerance is an environmental condition in a multi-node system.
PACELC adds the healthy-path trade-off: stronger consistency requires coordination, while lower latency can expose stale values.
Linearizability preserves the latest-write contract; causal consistency preserves dependencies while allowing concurrent operations to differ; eventual consistency guarantees convergence if writes stop but provides no deadline.
Choose consistency at the business-operation boundary: carts and feeds can often merge or recover from conflicts, while payments, inventory, reservations, and uniqueness checks need coordinated decisions.