Consistency models

01Consistency model: definition and example

Consistency has different meanings in different contexts. The familiar CAP definition is that clients observe one up-to-date copy: after a write completes, a later read must return it or a newer write. This is linearizability. A consistency model is the broader term for the rules governing when writes become visible and how operations may be ordered.

One example, two models: a record contains v10. Client A writes v11 and receives success. Client B then reads through another server, with no further writes.

1. Linearizability: a successful read must return v11. If the server cannot establish the current value, it must coordinate, wait or refuse rather than return stale v10.
2. Eventual consistency: the read may temporarily return v10. Once updates stop and propagation and reconciliation succeed under the system’s assumptions, reads converge on the settled value; the model alone gives no freshness deadline.

“Strong consistency” commonly refers to linearizability in interviews, but ask for the exact model and operation scope. “All clients see the same data” is shorthand for the observable single-copy behavior, not a requirement that every physical replica update simultaneously. The linearizability section explains overlapping operations.

Interview memory aid: CAP consistency asks “Do readers see the current value?”; a consistency model asks “What may readers observe?”; ACID consistency asks “Do the rules still hold?”

Define the scope before choosing a guarantee: one object, one session, or a multi-object operation. The bounded histories below use record N7, version 10 (“Trip”), followed by version 11 (“Autumn trip”). Client A writes the update; client B can read through a different replica in East or West. A history is the sequence of observed reads and writes. The timestamps and versions are illustrative, not measurements.

With a single process, an ordinary write followed by a read can access the same in-memory value. Replicas, caches, and concurrent clients break that intuition: the write can finish at East while West still has version 10. Before drawing servers, finish this sentence: “After this operation succeeds, these readers must be able to observe this state.” Specify whether the promise concerns one key, a session, or several keys together.

02Linearizability: real-time operation order

Plain-language definition: after a write completes, any read that starts later must return that write or a newer write. Clients observe one up-to-date copy of the object. This is the consistency guarantee used by CAP.

Formal definition: operations can be placed in one valid order, respecting real time, as though each took effect at one instant between its start and finish. This also defines what is allowed when operations overlap; the simple completed-write/later-read example below is one consequence. Herlihy and Wing’s original definition is the source of this formulation.

Apply these tests:

1. Respect completed operations. If client A’s title write finishes before client B starts a title read, client B must see that write or a later write in the object’s valid history.
2. Use the actual history. There are no intervening writes in this example, so the answer must be version 11.

Two limits to remember:

1. Overlapping operations can have either valid order. A read beginning at 10:00:00.5 can legally return v10 if its conceptual instant precedes the write’s instant. “Latest” is ambiguous during overlap; use the operation intervals.
2. Separate calls do not become one atomic action. A linearizable title register does not make a read-title/write-title pair atomic. Use conditional updates or transactions to prevent that race.

Do not confuse ordering individual operations with grouping several operations atomically:

03Sequential consistency: one order preserving each client

Now let client A write v11 and then read v10, with no other title write. This cannot be explained while preserving client A’s own operation order, so it violates sequential consistency too. The distinction is not “some replicas are usually slow”; it is a precise restriction on the histories clients may observe.

A consistent total order can be useful for reasoning, but sequential consistency alone gives client B no wall-clock freshness bound. Application messages outside the modeled interface also need careful treatment: if client A tells client B that the save finished through a separate channel, that real-world expectation is not automatically enforced by a model that only orders notebook operations.

04Causal consistency: dependent writes stay ordered

The preceding models ask whether operations fit one common order. Causal consistency instead preserves the order of operations that depend on one another, while allowing unrelated writes to be seen in different orders. In a discussion thread, the useful relationship is that a reply depends on the comment its author read.

Rule: A cause precedes its dependent effect. Program order, reading a value and acting on it, and chains of these relationships create causal dependencies.

Trace the dependency:

1. Create the parent. Client A writes comment C41, “Train at six.”
2. Observe and reply. Client B reads C41 and writes C42, “I will be there.”
3. Enforce visibility. A causal view exposing C42 must include its dependency C41. Otherwise the reply arrives without the information that explains it.

An implementation can attach dependency identifiers to C42 and delay its visibility at West until C41 is available. A timestamp alone does not fetch a missing dependency. The service must track and enforce the relevant relationships, including dependencies carried when a client changes servers.

Two independent comments, C43 from client A and C44 from client B, can be concurrent: neither author saw the other. Causal consistency does not require every reader to see those independent writes in the same order. If concurrent updates change the same title, conflict handling remains necessary. A deterministic winner converges, but may discard an edit; preserving alternatives or merging application operations gives a different product behavior.

Causal visibility describes applied history, not a requirement to display every earlier value forever. A later authorized deletion can replace a parent comment with a tombstone; the replica must still account for the dependency. Nor does causality make a multi-object update atomic: exposing half a transfer requires a transaction or an additional atomic-visibility protocol to prevent it.

05Session guarantees: read-your-writes and monotonic reads

A session is the scope over which the service remembers one client’s observations. Read-your-writes means client A’s later reads incorporate its completed writes. Monotonic reads mean that after it has observed a version, later reads do not retreat to an earlier state along that history. Neither alone requires every other user to see the globally newest value.

One implementation carries a session token describing the minimum history the next server must include. A replica’s applied position records how far it has incorporated that history into readable state. If its position is behind the token, the service waits, routes to a sufficiently current replica, or refuses the read; merely sending the token does not make the replica catch up.

The diagram follows a single ordered title history, where one number can identify how far the replica has applied that history. Multiple independently written objects may need a richer dependency representation. Pinning client A to East is simple but failover breaks the guarantee unless the new replica catches up or the request waits. A token must represent a real storage guarantee, not an arbitrary browser counter.

06Eventual consistency and bounded staleness

Eventual consistency promises convergence once updates stop and the system can exchange the necessary information under its recovery assumptions. East and West may temporarily disagree about N7. This does not promise that every replica converges within two seconds, nor does it by itself prevent client A from seeing v11 and then v10.

Bounded staleness adds a limit

These choices are not one universal ranking. Session guarantees concern a client’s continuity, causal consistency concerns dependencies, and a staleness bound concerns distance from a defined reference. State which promises are combined. For notebook search results we may tolerate delayed convergence, while the edit screen combines read-your-writes with monotonic reads. Both can coexist with a stricter ownership service.

Convergence is a promise about the eventual result; an implementation still needs a rule for reconciling updates accepted independently. Some data types can merge both contributions, while other designs choose one winning value and discard the alternative. CRDTs and last-write-wins illustrate these different conflict-handling choices.

CRDT: merge the same state without double counting

Conflict-free replicated data types (CRDTs) use defined update/merge rules so replicas that receive the same updates converge. For a state-based grow-only counter:

1. Keep local components. Each replica increments only its own counter entry. In the pair (A-count, B-count), A changes the first entry and B changes the second.
2. Merge by maximum. Take the maximum per component: A=(2,0) and B=(0,3) merge to (2,3).
3. Read by addition. Sum the components: 2 + 3 = 5. Repeating the merge does not count the increments twice.

For state-based CRDTs, merge must be associative (grouping merges differently gives the same result), commutative (merging A with B gives the same result as B with A), and idempotent (merging the same state again changes nothing). Updates must also obey the type’s rules. Operation-based variants have their own delivery requirements.

Last-write-wins chooses a winner

Interview check: Does a converged counter prove inventory was never oversold? No. Convergence of replicas and preservation of a business invariant are separate properties.

07Consistency-model comparison and failure behavior

For this hypothetical notebook, I choose session guarantees for the editing screen and causal visibility for threaded comments. These preserve understandable interaction without requiring every read to coordinate across regions. I use an authoritative, ordered ownership update and authorization path because a revoked collaborator must not gain access through a stale permissive replica. The security contract must explicitly address cached permissions and already-issued access, too.

Suppose East fails after client A receives token 11, while West has only version 10. The interface may keep the submitted text and show “reconnecting”; it must not present West’s older result as the saved current version. Wait for a replica that includes token 11 or return a retryable failure. If the storage policy allowed version 11 to be lost, routing cannot recover it. Consistency controls what reads may show; durability controls what saved data survives.

In an interview I would say: “I will define consistency per operation. A session’s reload must include its acknowledged save; replies require their parent; ownership checks use authoritative state. I will show the token or dependency mechanism, and I will specify what the service does when no reachable replica meets that promise.”

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.