The Spectrum of Consistency Models

Why this matters: the moment you have more than one replica, "what does a read return?" stops having an obvious answer. Consistency models are the vocabulary for specifying that precisely — and picking the wrong one is how you ship a system that is either mysteriously wrong or needlessly slow.

What is consistency?

In distributed systems, "consistency" has several definitions. It can mean that all replicas share the same view of the data, or that a read returns the most recent write. Consistency models provide abstractions for reasoning about data correctness during concurrent reads, writes, and mutations.

This is not academic. When you integrate a storage system — S3, Cassandra, DynamoDB, Spanner — you must know which guarantee it gives you, because your application code silently assumes one.

Models fall along a spectrum with two extremes: strongest and weakest, with several models in between.

Moving right, guarantees get stronger — and so do the coordination costs.

ACID consistency is not CAP consistency

These two words are the same and the concepts are unrelated. Interviewers ask this precisely because conflating them is so common.

ACID consistency enforces database rules. If a schema requires unique values, the system ensures no duplicates exist. If a foreign key links rows, the system prevents inconsistent states — such as deleting a base row while related rows still reference it.

CAP consistency guarantees that every replica holds the same logical value at any given time. Physical replication across a cluster takes time because of network latency, but the system ensures clients do not observe divergent values.

Eventual consistency

Eventual consistency is the weakest model. It guarantees only this: once writes stop, all replicas converge to the same final value. It says nothing about what happens before convergence — replicas may return stale or differing data.

Consider x = 2 replicated across an eventually consistent system:

At T1 Alice writes x = 10 and the system saves it. At T2 Alice and Bob both read x — and both get the old value 2, because they read from a replica that has not received the update yet. Note that Alice cannot even read back her own write; that is a real usability problem, and Lesson 7 is about fixing exactly it.

The upside is the reason this model dominates: eventual consistency enables high availability. A replica can answer immediately without coordinating with anyone, so reads and writes stay fast and stay up even during partitions.

Causal consistency

Causal consistency preserves the order of causally related operations. Operations with no dependency between them get no ordering guarantee at all.

Concretely: process P1 writes value a at location x. Process P2 reads x and uses it to compute b = x + 5, then writes b to location y. Because the write to y depends on the read of x, the two operations are causally related — and every observer must see them in that order.

Causal consistency does not order unrelated operations, so different clients may observe those in different sequences. It is weaker than sequential consistency and stronger than eventual consistency, and it buys the thing that matters most in practice: it prevents non-intuitive behavior in dependent data.

Example: a commenting system. A reply must never appear before the comment it replies to — that cause-and-effect relationship is exactly what causal consistency preserves. Two unrelated top-level comments arriving in different orders for different users is harmless; a reply to a comment nobody can see is not.

Sequential consistency

Sequential consistency is stronger than causal. It preserves the order of operations specified by each client's program — every client's operations appear in the order that client issued them, and all observers agree on one single interleaving.

What it does not promise is real time. A write may become visible some time after it was acknowledged; there is no guarantee of instantaneous visibility.

Example: a social network feed. Users expect one friend's posts to appear in the order that friend created them. The relative ordering of posts from different friends matters much less. Sequential consistency delivers exactly that: per-client program order, globally agreed, without the cost of real-time guarantees.

Strict consistency (linearizability)

Strict consistency, usually called linearizability, is the strongest model. A read returns the most recent write, full stop. Once a write is acknowledged, every subsequent read by any client reflects that value immediately.

This is difficult to achieve in a distributed system because network delays vary and nodes fail. Consider three nodes and three users, all starting at x = 2:

Look closely at the danger window. Node A acknowledged Alice's write before Nodes B and C had it. If John reads from Node C during that window, he gets 2 — after the write was already confirmed. That violates linearizability.

Closing that window is the entire engineering problem. Strong consistency therefore relies on synchronous replication and consensus algorithms such as Paxos and Raft. Because linearizability directly costs availability, real systems use quorum-based replication to balance the two: acknowledge only after a majority has the write, so any majority read must intersect it.

Example: password updates. If a user changes their password after suspicious activity, the old password must be invalid immediately everywhere. A stale replica still accepting the old credential is a security incident, not a stale read.

Linearizable is not serializable

The most common senior-level confusion, and worth being crisp about:

Serializability permits an execution equivalent to some serial order — not necessarily the real-time one, so it alone allows stale reads. Linearizability fixes recency but says nothing about grouping operations atomically. Systems that need both advertise strict serializability.

Summary

• Linearizable services execute operations in a sequential, real-time order. This makes application development dramatically simpler and limits scalability and availability.
• Strong consistency models generally mean lower performance. Guaranteeing a read returns the absolute latest write requires coordination, and coordination is latency.
• Weaker models offer higher performance and availability, but move the burden into your application: you must now handle staleness and out-of-order updates in business logic.

Interview signal by level

Next: the guarantees users actually notice — and eventual consistency's most annoying bug.