Consistency models

Consistency is a contract about what a read may return

Once data exists in more than one place — a replica, a cache, a second region — "what is the current value?" stops having a single answer. A consistency model is the contract you offer the application about which of the possible answers a read is allowed to produce. Stronger models forbid more answers, which costs coordination, which costs latency and availability.

Interviewers push on this because it is the one topic where candidates reliably say something confidently wrong ("we'll use eventual consistency for speed") without noticing they just permitted a user to see their own comment disappear. The senior move is to pick a model per operation and justify it in product terms.

Replication lag is the concrete thing underneath all of it

"Eventual consistency" sounds abstract until you attach numbers to it. Lag is the wall-clock delay between a write committing on the primary and being visible on a given replica, and its distribution is wildly skewed — the median is boring and the tail is where your bugs live.

The operationally important property: lag is not bounded. Any design that says "the replica is only a few milliseconds behind, so it's fine" is a design that breaks during the exact incident where correctness matters most. If you need a bound, you must enforce one — by reading the primary, by waiting for a version token, or by refusing to serve from a replica whose lag exceeds a threshold.

The two poles, and the useful middle

Strong consistency (informally: every read sees the latest committed write) requires the read to be coordinated with the write. The usual ways are to send the read through the leader after it has confirmed it is still the leader (Raft's ReadIndex, or a clock-based leader lease), or, in a leaderless register, to read a quorum and write the newest value back to a quorum before returning (the ABD algorithm). A plain "read R replicas and take the newest" is not enough, as the warning below shows. Cost: at least one extra round trip, and unavailability whenever the leader or a quorum is unreachable. Eventual consistency promises only that if writes stop, replicas converge. Cost: nothing; guarantee: nearly nothing. Any stale value is legal, in any order, on any read.

Between them sit the session guarantees — the models that actually ship in real products, because they fix the anomalies users can perceive without paying for global coordination.

Quorums: R + W > N, with the numbers worked out

In a leaderless or quorum-replicated store (Dynamo, Cassandra, Riak) you choose three numbers: N replicas hold each key, a write must be acknowledged by W of them, a read must gather R of them. If R + W > N, the read set and the write set must overlap in at least one node by pigeonhole — so at least one responding replica has the newest write, and version stamps let the reader pick it.

Latency follows directly: a W=2 write waits for the second-fastest of three replicas, so it inherits that node's p95, not the fastest node's. Raising W or R moves you further into the tail of the slowest responder — which is why quorum systems tune these per-query rather than globally.

Dry run: N=3, W=2, R=2 — and what breaks it

The pigeonhole argument only holds while every acking node is a genuine member of the key's preference list. The moment a sloppy quorum lets an outsider count toward W, the read set and write set can miss each other entirely — which is exactly why R + W > N is a normal-operation guarantee, not a partition-tolerant one. Which systems do this? Riak and the original Dynamo paper use sloppy quorums by design. Cassandra does not: its hinted handoff lets a hint satisfy a write only at consistency level ANY, so at ONE, QUORUM or higher the acks must come from real replicas and the overlap argument holds.

Linearizability vs serializability — telling them apart for good

They sound like synonyms, they come from different fields, and mixing them up is the fastest way to lose credibility on this topic.

• Linearizability is about single objects and real time. Every operation appears to take effect instantaneously at some point between its invocation and its response, and that point respects wall-clock order: if write W completes before read R begins, R must see W. It says nothing about multi-key transactions. It is a recency guarantee — the C in CAP.
• Serializability is about multi-object transactions and says nothing about real time. Concurrent transactions produce a result equivalent to some serial order — and that order need not match the order they actually happened in. A transaction that committed an hour ago may legally be ordered after one committing now. It is an isolation guarantee — the I in ACID.
• Strict serializability is both: a serial order that also respects real time. Spanner (via TrueTime) is the system that uses the term "external consistency" for it; FoundationDB documents strictly serializable transactions too. CockroachDB deliberately claims only serializability, because clock skew can produce a "causal reverse" anomaly between transactions that touch disjoint keys. Strict serializability is the strongest practical model.

The one-liner worth memorising: linearizability is about recency of a single key; serializability is about the illusion of one-at-a-time transactions. A database can be serializable and still let you read stale data: a transaction run against a lagging follower snapshot, or one serialised at an old timestamp, is a valid serial order that is not the newest one. (Postgres sidesteps this: a hot standby refuses SERIALIZABLE transactions outright.) And linearizable does not mean "no transactions": etcd offers atomic multi-key transactions and documents strict serializability for its default reads, while a single register with compare-and-set is linearizable with no multi-object transactions at all. ZooKeeper is the cautionary case: writes go through a leader in a total order, but reads are served locally by whichever server you are connected to and can be stale unless you call sync() first.

Between these sits snapshot isolation, which many databases ship as the strongest level they call "serializable" or as the default "repeatable read". It prevents dirty and non-repeatable reads, but still allows write skew (two doctors each see the other on call and both go off call), lost updates in some engines, and phantoms for range checks. The fix is a true serializable level, or an explicit constraint, SELECT ... FOR UPDATE, or a conditional write. Isolation levels get their own chapter; the point here is that "transactional" does not automatically mean "serializable".

Choosing per operation: model, cost, and what it looks like to a user

Recognizing it in an unseen problem

• Signals: the moment your diagram grows a read replica, a cache, or a second region, you have chosen a consistency model — the only question is whether you chose it deliberately. "Multi-region", "read replicas", "global users" are all consistency prompts in disguise.
• The naive design says "we'll use eventual consistency, it's more available" and then puts a write-then-read flow on top of it. Almost every user-visible consistency bug is a read-your-writes violation, not a deep causality problem.
• Distinguishing it from CAP hand-waving: CAP is a statement about behaviour during a network partition, which is rare. Replication lag is present every single second of normal operation. Talk about lag; mention CAP only if partitions are actually in scope.
• Uniqueness and inventory are not consistency-tunable. If two concurrent operations must not both succeed, no choice of R and W saves you — you need a single point of serialisation. Say that explicitly; it's a common trap.
• Quantify. "Cross-region lag is ~100 ms, so a European read of a US write can be stale for a tenth of a second — fine for a like count, not for a payment confirmation" is worth more than three paragraphs of theory.
• The pitfall to avoid: using "strongly consistent" and "serializable" interchangeably. If you only remember one thing: linearizability = recency of one key; serializability = transactions appear one-at-a-time.