Linearizability

In practice

Linearizability is a recency guarantee about one object. Serializability is an ordering guarantee about multi-object transactions. They are orthogonal axes, and conflating them is the most common mistake in this whole area — "strictly serializable" is the model that gives you both.

The test is simple: if client A's write completes at 10:00:00.000, can client B read the old value at 10:00:00.001? Under linearizability, no. Under anything weaker, yes.

What it costs: at least one round trip to a quorum on every read, or reads served only by the leader. Cross-region, that is 30–150 ms of unavoidable latency per operation — the PACELC "else latency" term made concrete.

Systems that offer it: etcd, ZooKeeper, Spanner (TrueTime), DynamoDB with ConsistentRead, single-leader Postgres reads on the primary.

When it matters

Distributed locks, leader election, uniqueness constraints, sequence generation, and any read that gates a decision the user immediately acts on — "did my payment go through?"

Common mistake

Turning on strong reads globally because it sounds safer. Most reads in a product are display reads that tolerate 200 ms of staleness. Paying quorum latency on all of them to protect the 2% that genuinely need it is how a system ends up slow everywhere and no more correct where it counts.