The Gold Standard
Linearizability (also called Atomic Consistency) is the strongest practical consistency model. Its goal is to make a distributed, replicated system appear exactly as if it were a single, non-replicated machine with a single copy of the data.
The rule is simple: once an operation (a read or a write) is completed and acknowledged to the client, its result is immediately visible to all subsequent operations by any client, anywhere in the system. It respects the real-time ordering of events — if operation A finishes before operation B starts (by wall clock), then B must observe the effects of A.
Example: The Scoreboard
Imagine a global sports scoreboard.
- A referee in London updates the score to "1-0". The write operation completes and is acknowledged at 12:00:00 UTC.
- At 12:00:01 UTC, a fan in Sydney refreshes their app.
Under linearizability, the fan must see "1-0". They cannot see the old "0-0" score. Every read that starts after a write finishes must see that write's value (or a newer one). The system behaves as if there is one authoritative scoreboard, even though there are dozens of replicas.
How It Works Mechanically
Achieving linearizability requires that before acknowledging a write, the system ensures a quorum of nodes has accepted it. Reads must also contact a quorum to confirm they are seeing the latest value. Algorithms like Raft and Paxos implement this coordination. The leader node serializes all operations, assigns them a global order, and only responds to the client after a majority of replicas confirm the operation.
This is why linearizable systems like etcd (used by Kubernetes for cluster state) are slower than eventually consistent databases — every operation pays the cost of a round-trip coordination across the cluster.
The Cost
Linearizability requires heavy coordination between nodes. This makes the system:
- Slower (higher latency): Every write must wait for quorum acknowledgment before completing.
- Less available: If a quorum of nodes can't communicate (network partition), the system must stop processing writes rather than risk returning stale data. This is the direct consequence of the CAP theorem — a linearizable system chooses Consistency over Availability during a partition.
Interviewers frequently ask: "What's the difference between linearizability and serializability?" These sound similar but apply to different scopes. Linearizability is a property of individual read/write operations on a single object — it's about real-time ordering. Serializability is a property of transactions involving multiple objects — it guarantees that concurrent transactions produce a result equivalent to some serial execution. A system can be serializable but not linearizable (transactions are ordered, but not necessarily in real-time order). Systems like Google Spanner achieve both, which is called strict serializability.