Linearizability is the gold standard of consistency for a single object or register. It says: every operation appears to take effect instantaneously at some point between when the client sent it and when the client received the response. Once a write completes, every subsequent read — from anywhere in the system — must see that write or a later one. No exceptions, no "eventually."

This is stronger than serializability (which is about transactions) and stronger than sequential consistency (which only preserves per-process order). Linearizability adds a real-time guarantee: if write W completes at wall-clock time T1, and read R starts at T2 > T1, R must see W. The system behaves as if there's one copy of the data, accessed one operation at a time, in real time.

Real-world example: etcd and ZooKeeper provide linearizable reads and writes for their key-value store. When Kubernetes writes "Pod X is now scheduled on Node Y" to etcd and the API server returns success, every subsequent kubelet query — anywhere in the cluster — sees that assignment. The scheduler relies on this: without linearizability, two schedulers could each read "no pod assigned," both write their own assignment, and you'd have a split-brain pod. Compare-and-swap on a linearizable store is what makes leader election actually work.

How it's implemented: typically through a consensus protocol (Raft, Paxos, Multi-Paxos). Writes go through the leader, get replicated to a quorum, and only then return success. Reads either go through the leader (with a lease) or perform a "ReadIndex" round trip to confirm leadership before returning. That round trip is the cost.

The cost — a rule of thumb: linearizable operations require at least one round trip to a quorum. In a 3-node cluster across availability zones with 2ms inter-AZ latency, expect ~4–6ms minimum latency per operation, plus disk fsync time. Cross-region (50ms RTT)? You're looking at 100ms+ per write. That's why nobody runs linearizable systems across continents for hot paths.

When to demand it: leader election, distributed locks, configuration changes, financial ledgers where double-spend is fatal, unique ID generation. When to avoid it: user feeds, view counts, product catalogs, anything where stale-by-a-few-seconds is fine. Linearizability is a tax — pay it only where correctness genuinely requires real-time ordering.

One subtle trap: linearizability is a per-object property. A linearizable KV store does not give you linearizable multi-key transactions. For that you need strict serializability — linearizability plus serializability — which is what Spanner provides via TrueTime, and why TrueTime needs atomic clocks.