Linearizability

A strong consistency model in which the system behaves as if there were a single copy of the data and every operation took effect atomically at some instant between its start and end. Once any read sees a new value, all later reads see it too; the data never appears to go back to a stale state.

Why it Matters

It is the simplest model to reason about, because it makes a replicated, distributed store look like one non-replicated variable. But it is costly: it requires coordination, adds latency, and cannot be fully available during a network partition, so it should be reserved for the cases that truly need it.

Signals

• Requirements like "after I write, everyone must immediately read the new value."
• Correctness that depends on a single, current view of the data.
• A hard uniqueness, locking, or leader-election guarantee.

Benefits

Removes whole classes of concurrency bugs by giving every reader a single, up-to-date view of the data.

Risks

Assuming a store is linearizable when it is only eventually consistent; paying the coordination and availability cost where a weaker guarantee would do.

Tensions

Linearizability versus availability and performance: under a partition you cannot have both linearizability and full availability, and even without partitions it adds coordination latency.

Examples

A username-uniqueness check that must never allow duplicates; a distributed lock that two clients must never hold at the same time.