Linearizability
The strongest consistency guarantee: every operation appears to take effect atomically at some point between its invocation and completion. As if there's a single copy of the data.
What is Linearizability?
In short
Linearizability is the strongest single-object consistency guarantee: every read and write appears to happen instantly at one moment between when the operation was sent and when it returned, so the system behaves as if there is one single copy of the data that everyone sees in real-time order. Once a write completes, every later read anywhere must see that write or a newer one.
What linearizability actually means
Linearizability is a correctness condition for concurrent operations on a single piece of data, such as one key or one register. It says that even though many clients send overlapping requests to a replicated system, you can always find a single point in time for each operation, somewhere between its start and its finish, where it took effect atomically. The operations laid out by those points form one sequential order that respects real time.
The practical promise is simple. If a write finishes at 10:00:00.200, any read that starts after that instant, on any replica, anywhere in the cluster, must return that value or something written even later. You can never read a stale value once a newer one has been confirmed. This is why people say linearizability makes a distributed store behave like a single thread touching a single variable.
It is sometimes called atomic consistency or external consistency. It is a guarantee about one object at a time. It does not by itself promise that a group of operations across many objects happens as one unit. That is what serializability and strict serializability cover, and the two ideas are often combined.
How systems achieve it under the hood
The usual way to get linearizability is a consensus protocol that forces every replica to agree on one ordered log of writes. Raft and Multi-Paxos elect a single leader, and every write goes through that leader, which assigns it a position in the log and waits for a majority of replicas to acknowledge it before telling the client it succeeded. Because a majority must store each entry, no two conflicting values can both be committed.
Reads need care too. A follower that has fallen behind could answer with old data, which breaks the guarantee. Systems fix this by routing reads through the leader, or by having the leader confirm it is still the leader with a quorum before answering, or by using a read index where the leader waits until it has applied all committed entries. etcd and Consul expose both a fast read mode and a strict linearizable read mode for exactly this reason.
The cost is coordination. Every linearizable write, and often every strict read, requires a round trip to a quorum, so latency tracks the slowest member of the majority. Spread your replicas across continents and a single write can cost tens to hundreds of milliseconds. This is the concrete reason the CAP theorem bites: during a network partition a linearizable system must reject requests on the minority side rather than serve possibly stale data, so it gives up availability to keep consistency.
When to use it and the trade-offs
Reach for linearizability when correctness depends on everyone seeing the latest value immediately: leader election, distributed locks, unique ID or sequence allocation, configuration that gates other behavior, and account balances where a double spend is unacceptable. In these cases a stale read is not a minor annoyance, it is a bug that can cost money or split your cluster.
Avoid paying for it where you do not need it. A social feed, a product catalog, view counts, or a user profile can tolerate a value that is a second or two old, so eventual or causal consistency gives you far lower latency and better availability. Linearizing those reads just burns quorum round trips for no user-visible benefit.
Be precise about the boundary. Linearizability is per object. A bank transfer that debits one account and credits another touches two objects, so you need a transaction with serializable isolation, not just linearizable single-key writes. Mixing the two up is a common source of subtle bugs where each key looks correct but the combination is not.
A concrete example
Picture a distributed lock stored in etcd. Client A acquires the lock by writing its ID with a compare-and-set that only succeeds if the key is empty. etcd runs that write through Raft, a majority of nodes persist it, and only then does A get a success response. The write is now linearized at the moment it committed.
Client B, running in another data center, then tries the same compare-and-set. Because B's request is ordered after A's committed write in the single Raft log, B sees the key is already taken and fails. There is no window where both clients believe they hold the lock, even though their requests overlapped in wall-clock time and hit different nodes.
Now imagine the network splits A's node from the majority. A's node can no longer reach a quorum, so it stops accepting writes and even stops serving strict reads, rather than handing out a stale view that lets B grab a lock A still thinks it owns. That refusal is linearizability doing its job: it would rather be unavailable than wrong.
Where it is used in production
etcd
Kubernetes' control-plane store; uses Raft to give linearizable reads and writes for cluster state and leader election.
ZooKeeper
Provides linearizable writes through its Zab atomic broadcast protocol, powering locks and config for Kafka, HBase, and others.
Google Spanner
Uses TrueTime atomic clocks plus Paxos to offer strict serializability, which is linearizability combined with serializable transactions across regions.
Amazon DynamoDB
Offers strongly consistent reads that are linearizable per item, in addition to the cheaper eventually consistent default reads.
Frequently asked questions
- What is the difference between linearizability and serializability?
- Linearizability is about single objects and real-time order: each operation on one key appears to happen at one instant, and a finished write is visible to all later reads. Serializability is about transactions over many objects: a set of transactions appears to run one after another in some order, but that order need not match real time. Strict serializability is the combination of both.
- Is linearizability the same as strong consistency?
- People often use strong consistency to mean linearizability, and that is the common reading. But strong consistency is a loose marketing term that can also refer to serializability or just no stale reads, so when precision matters say linearizability explicitly.
- Why does linearizability hurt availability during a network partition?
- To stay linearizable you must confirm each write with a majority quorum. If a partition cuts a node off from the majority, it cannot confirm reads or writes, so it must reject requests instead of serving possibly stale data. That is the CP corner of the CAP theorem: consistency over availability.
- Do reads also need to be coordinated, or only writes?
- Reads need coordination too. A replica that lagged behind could return an old value and break the guarantee. So linearizable reads either go through the leader, confirm leadership with a quorum first, or wait on a committed read index. This is why strict reads cost more than eventually consistent reads.
- Does linearizability mean my whole database is consistent?
- No. It is a per-object guarantee. Each key can be linearizable while a multi-key operation still races. To make a group of keys change atomically you need transactions with serializable isolation on top of, or instead of, single-key linearizability.
Learn Linearizability hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Serializability
A guarantee that concurrent transactions produce the same result as if they were executed one at a time in some serial order. The gold standard for database transaction isolation.
Strong Consistency
A guarantee that after a write completes, all subsequent reads will return the updated value. Safer but slower than eventual consistency.
CAP Theorem
In a distributed system, you can only guarantee two of three: Consistency, Availability, and Partition tolerance. You must choose your trade-off.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
Snapshot Isolation
A consistency level where each transaction reads from a consistent snapshot of the database taken at the transaction's start time. Prevents dirty reads without full serializability overhead.
Causal Consistency
A consistency model that preserves cause-and-effect ordering: if operation A causally precedes B, all nodes see A before B. Weaker than linearizability but stronger than eventual consistency.