Strong Consistency
A guarantee that after a write completes, all subsequent reads will return the updated value. Safer but slower than eventual consistency.
What is Strong 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.
What Strong Consistency Actually Guarantees
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.
How It Works Under the Hood
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.
When To Use It And The Trade-offs
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.
A Concrete Example
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.
Where it is used in production
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.
Frequently asked questions
- What is the difference between strong consistency and eventual consistency?
- 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.
- Is strong consistency the same as linearizability?
- 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.
- Why is strong consistency slower?
- 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.
- Does strong consistency mean my system cannot be highly available?
- 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.
- How do I get strong consistency in practice?
- 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.
Learn Strong Consistency 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.
Related lessons
Lessons that touch on Strong Consistency as part of a larger topic.
Linearizability
The strongest consistency guarantee, every operation appears to take effect at a single instant
advanced · consistency models
Write-Through Cache
Every write hits both the cache and the database, strong consistency at the cost of write latency
foundation · caching strategies
BASE Properties
Distributed system consistency model that trades strong consistency for availability
foundation · core fundamentals
See also
Related glossary terms you might want to look up next.
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
In a distributed system, you can only guarantee two of three: Consistency, Availability, and Partition tolerance. You must choose your trade-off.
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.