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
A guarantee that after a write completes, all subsequent reads will return the updated value. Safer but slower than eventual consistency.
In short
Strong consistency is a guarantee that once a write completes, every later read from any node returns that written value or a newer one, never a stale one. It makes a distributed system behave as if there is a single copy of the data, at the cost of higher latency and reduced availability when nodes are partitioned.
In short
Strong consistency is a guarantee that once a write completes, every later read from any node returns that written value or a newer one, never a stale one. It makes a distributed system behave as if there is a single copy of the data, at the cost of higher latency and reduced availability when nodes are partitioned.
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 Strong Consistency across a run of lessons, not one page. These 4 alone are about 84 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.
Distributed system consistency model that trades strong consistency for availability.
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee.
The full spectrum from eventual to strong, understand every model and when you need each one.
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
Strong consistency means the system gives every reader the most recent successful write. If a client writes value=5 and the write returns success, no client anywhere can later read the old value=4. The system hides the fact that data is stored on many machines and makes it look like there is one single copy that everyone shares.
The strictest common form is linearizability. Under linearizability, every operation appears to happen instantly at one point in time, somewhere between when the client sent the request and when it got the response, and that order matches real wall-clock time. A close cousin is sequential consistency, which keeps a single global order but does not require it to line up with real time.
Contrast this with eventual consistency, where reads may return stale data for a while and the replicas only agree if you stop writing and wait. Strong consistency removes that waiting. The trade is that the system has to do extra coordination on every write before it can call the write done.
The usual machinery is a consensus protocol such as Raft or Paxos, or a quorum scheme. With Raft, one node is elected leader. All writes go through the leader, which appends the change to a replicated log and waits until a majority of nodes acknowledge it before responding to the client. Because a majority must agree, any later read served by the leader reflects every committed write.
Quorum systems use the rule R + W > N, where N is the number of replicas, W is how many must accept a write, and R is how many must answer a read. If you write to 2 of 3 replicas and read from 2 of 3, the read set and write set always overlap on at least one node, so the reader sees the latest value. Set W=N or R+W>N and you get strong reads.
All of this costs round trips. A write is not done until enough remote nodes confirm it, which adds network latency, often crossing data centers. During a network partition the system must refuse some operations rather than serve possibly stale data, which is the unavailability side of the CAP theorem.
Reach for strong consistency when a stale read is a correctness bug, not a cosmetic glitch. Bank balances, inventory counts, payment idempotency, unique username registration, distributed locks, and leader election all break badly if two nodes disagree about the truth. A double-spend or a negative inventory count is far worse than a few extra milliseconds of latency.
The cost is real. Every write pays for coordination, so throughput drops and tail latency rises, especially across regions where a quorum round trip can be 100 milliseconds or more. The CAP theorem says that during a partition you must give up either consistency or availability, and strong consistency chooses to stay consistent and reject requests it cannot safely serve.
Many large systems split the difference. They keep strongly consistent stores for money and identity, and push high-volume, low-stakes data such as view counts, feeds, or recommendation caches into eventually consistent stores. The skill is deciding which data truly needs the guarantee, because applying it everywhere makes the whole system slow.
Imagine a flash sale with one item left in stock. Two customers click buy at almost the same moment. Under strong consistency, the inventory service runs both decrements through a single ordered path. The first request commits, stock goes from 1 to 0, and the second request reads 0 and is rejected. Exactly one sale happens.
If the same inventory lived in an eventually consistent store, both requests could read stock=1 on different replicas, both decrement, and you oversell. Now you have to email a customer that their order is canceled. Google built Spanner specifically so that this kind of globally distributed transaction can stay strongly consistent across continents, using synchronized clocks to order writes.
The lesson engineers internalize: strong consistency is what lets you reason about a distributed system as if it were a single machine. You pay for that simplicity in latency, and you choose to pay it only where being wrong is expensive.
Google Spanner
Provides externally consistent, globally distributed transactions using TrueTime atomic clocks to order writes across data centers.
etcd
Uses the Raft consensus protocol for a strongly consistent key-value store that backs Kubernetes cluster state and leader election.
PostgreSQL
A single primary with synchronous replication gives strong consistency for reads served by the primary, used for financial and transactional data.
Amazon DynamoDB
Offers an opt-in strongly consistent read flag that returns the latest committed value at the cost of higher latency and more capacity units.
Strong consistency guarantees that once a write succeeds, every later read returns that value or newer, with no stale reads. Eventual consistency allows reads to return old data for a while and only promises that replicas converge if writes stop. Strong is safer; eventual is faster and stays available during partitions.
Linearizability is the strictest form of strong consistency: every operation appears to take effect instantly at one moment, ordered by real time. Strong consistency is the broader category and can also include weaker but still single-order models like sequential consistency. People often say strong consistency to mean linearizability in practice.
Every write has to coordinate with other replicas before it is acknowledged. A consensus protocol waits for a majority to confirm, and a quorum read may contact multiple nodes. These extra round trips add network latency, which is significant when replicas sit in different regions.
During a network partition you must choose between consistency and availability, per the CAP theorem, so a strongly consistent system will reject some requests rather than serve stale data. When the network is healthy it can be fast and available; the trade-off only bites during partitions.
Use a database or store that supports it: a consensus-backed system like etcd or Spanner, a single-primary SQL database with synchronous replication, or a quorum store configured so R + W > N. Many systems let you opt in per request, such as DynamoDB's strongly consistent read flag.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
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.
ACID
Four guarantees for database transactions: Atomicity (all or nothing), Consistency (valid states only), Isolation (no interference), Durability (changes persist).
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.
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.
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 Strong Consistency 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.
