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 consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
In short
Eventual consistency is a consistency model used by distributed databases where a write does not reach every replica at the same instant. Different replicas can return different values for a short window, but if writes stop, all replicas converge to the same final value, usually within milliseconds to a few seconds.
In short
Eventual consistency is a consistency model used by distributed databases where a write does not reach every replica at the same instant. Different replicas can return different values for a short window, but if writes stop, all replicas converge to the same final value, usually within milliseconds to a few seconds.
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 Eventual Consistency across a run of lessons, not one page. These 4 alone are about 124 minutes of step-by-step reading, every one with a quiz.
Distributed system consistency model that trades strong consistency for availability.
How read repair fixes stale replicas during a quorum read in Dynamo-style databases. Compares blocking and background repair, and other repair tools.
The full spectrum from eventual to strong, understand every model and when you need each one.
How distributed databases resolve replication conflicts: CouchDB's deterministic winner and _conflicts, Riak's mergeable siblings, last-write-wins, and merges.
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 BASE Propertiespay once,
yours for life
When you store data in more than one place, you have to choose how fast every copy must agree. Strong consistency says every reader sees the latest write immediately, no matter which copy they hit. Eventual consistency relaxes that promise: a write lands on one replica first, then spreads to the others in the background. For a brief window, a reader talking to a lagging replica can see stale data.
The word eventually is the whole guarantee. There is no fixed deadline in the basic model, only the promise that if you stop writing, every replica will end up holding the same value. In practice that window is short. Amazon's DynamoDB and Apache Cassandra typically converge in single-digit to low double-digit milliseconds inside one region, and seconds across distant regions.
This is the availability side of the CAP theorem trade-off. During a network partition, an eventually consistent system stays available and answers reads and writes on whatever replicas it can reach, accepting temporary disagreement instead of refusing to respond.
A client writes to one node. That node acknowledges the write quickly, then replicates it to the other copies asynchronously, often through gossip protocols, replication logs, or hinted handoff when a target replica is temporarily down.
Because writes can arrive in different orders on different nodes, the system needs a way to decide which version wins when two replicas disagree. Two common tools are last-write-wins using timestamps, and vector clocks or version vectors that detect concurrent writes so they can be merged rather than blindly overwritten. Anti-entropy background jobs and Merkle tree comparisons then scan replicas to find and repair divergence.
Quorum tuning gives you a dial. In a system with N replicas, you pick how many must acknowledge a write (W) and how many must answer a read (R). When R plus W is greater than N you get read-your-writes style strong guarantees, and when their sum is N or less you stay eventually consistent but faster and more available. Cassandra exposes this directly through consistency levels like ONE, QUORUM, and ALL.
Reach for eventual consistency when availability and low latency matter more than every reader seeing the newest value instantly. Shopping cart contents, social feed counts, view counters, product catalogs, DNS records, and user presence all tolerate a stale read of a few hundred milliseconds without any real harm.
Avoid it where a stale read causes a wrong decision. Bank balances during a transfer, inventory at the moment of checkout, unique username assignment, and anything that must never double-spend usually need strong consistency or a transactional database instead.
The hidden cost is application complexity. Your code must handle reading its own write and getting back an old value, conflicting concurrent updates, and the need for idempotent operations so a retried or reordered message does not corrupt state. You trade server-side simplicity for client-side defensive logic.
There are stronger flavors that narrow the gap. Read-your-writes consistency guarantees you always see your own updates, monotonic reads guarantee you never see time go backwards, and causal consistency preserves cause-and-effect ordering, all without paying the full price of global strong consistency.
Picture a Like button on a viral post. Ten thousand people tap it within a second, and those taps land on replicas spread across three continents. If the system demanded strong consistency, every Like would block until all replicas agreed on the new count, and the button would feel slow under that load.
With eventual consistency, each replica accepts its local taps instantly and replicates them in the background. For a few seconds two users might see 9,980 and 10,005, which is harmless. Background reconciliation sums the increments, and within a moment every viewer converges on the same total.
This is exactly the bet Amazon described in the original Dynamo paper: a customer adding an item to a cart should never be told no because one replica is unreachable. They accept that two writes might briefly diverge, then merge the carts later so nothing the customer added is lost.
Amazon DynamoDB
Defaults to eventually consistent reads that are cheaper and faster, with an optional strongly consistent read flag per query.
Apache Cassandra
Tunable per-query consistency through quorum levels, letting you pick eventual or strong on a write-by-write basis.
Amazon S3
Used eventual consistency for overwrite reads for years; replicas converged in the background after a PUT.
DNS
The global domain name system is eventually consistent by design; record changes propagate as caches expire over their TTL.
No. It still guarantees that all replicas converge to the same value once writes stop. The only relaxation is timing: it does not promise that every reader sees the newest write at the same instant, but it does promise they will all agree in the end.
Usually milliseconds. Inside a single region, systems like DynamoDB and Cassandra converge in single-digit to low double-digit milliseconds. Across distant regions or during a network partition it can stretch to seconds, and only the partition case pushes it longer.
Strong consistency makes every read return the most recent write, often by blocking until enough replicas agree, which costs latency and availability. Eventual consistency answers immediately from whatever replica is reachable and reconciles in the background, trading freshness for speed and uptime.
Common strategies are last-write-wins using timestamps, version vectors or vector clocks that detect concurrent edits so they can be merged, and CRDTs that are designed to merge automatically without conflict. The right choice depends on whether losing one of two concurrent writes is acceptable.
Yes. You can route a user's reads to the same replica that took their write, use sticky sessions, or set the read and write quorum so R plus W is greater than N. Many systems also offer a per-request strongly consistent read option for exactly these cases.
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.
BASE
An alternative to ACID for distributed systems: Basically Available, Soft state, Eventually consistent. Trades strong consistency for availability.
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 "BASE Properties" 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 BASE Properties lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Eventual 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.
