We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Consistency Models
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Linearizability across a run of lessons, not one page. These 4 alone are about 92 minutes of step-by-step reading, every one with a quiz.
The strongest consistency guarantee, every operation appears to take effect at a single instant.
All nodes see operations in the same order, though not necessarily real-time order.
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee.
Writes from a single client are applied in order, preventing write reordering across replicas.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Linearizabilitypay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
Clock Skew
The difference in time readings between clocks on different machines. Physical clocks drift; NTP helps but can't guarantee perfect sync. Why distributed systems use logical clocks.
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.
This page explains the idea. The "Linearizability" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Linearizability lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Linearizability in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
