Eventual Consistency
Date: 2026-08-17
Accepting that copies of data disagree for a while in exchange for availability and speed. It’s not a database exotica — it’s the reason a customer updates their basket and sees the old one, and the reason two analytics tools never quite agree.
Eventual consistency guarantees that if writes stop, all replicas will converge on the same value — but says nothing about when. Strong consistency guarantees every read returns the latest write, at the cost of coordination.
STRONG EVENTUAL
every read sees the reads may be stale
latest write for a window
coordination required no coordination
higher latency lower latency
unavailable during a available during
partition a partition
Why anyone accepts staleness
Because the alternative is worse for most data:
STRONG CONSISTENCY REQUIRES
the write to reach a quorum before
acknowledging
→ every write pays cross-node latency
→ a partitioned node must refuse
to answer
For a product description, refusing to serve is absurd. For a bank balance, serving a stale one might be. The right choice is per-data, not per-system — CAP Theorem.
Where you meet it without noticing
READ REPLICAS
write → primary, read → replica
replication lag: milliseconds to
seconds
CDN AND HTTP CACHES
a cached page is eventually consistent
by design
SEARCH INDEXES
a product updated in the database
appears in search seconds later
ANALYTICS PIPELINES
events land in the warehouse minutes
or hours after they happen
DNS
a record change propagates as caches
expire
See: CDN Caching · DNS
Almost every system you work with is eventually consistent somewhere. The question is only whether that fact is designed around or discovered in production.
The anomalies, named
READ-YOUR-WRITES
you update your profile, reload,
see the old name
← the read hit a lagging replica
MONOTONIC READS
you refresh and see OLDER data than
the previous refresh
← two reads hit different replicas
with different lag
CONSISTENT PREFIX
you see a reply before the comment
it replies to
← writes arrived out of order
Read-your-writes is the one that generates support tickets, because the user knows what they just did and the screen disagrees.
Fixes that actually work
ROUTE READS TO THE PRIMARY
for a short window after a user
writes — the standard fix, cheap
READ FROM THE WRITE RESPONSE
the API returns the updated object;
render that rather than refetching
STICKY SESSIONS
pin a user to one replica so at
least their view is monotonic
OPTIMISTIC UI
show the intended state immediately,
reconcile when confirmed
← be careful: this hides genuine
failures unless you handle them
The second is the most under-used. Returning the created or updated resource in the response removes an entire round trip and the staleness window with it.
Conflict resolution
When two replicas take conflicting writes, someone must decide:
LAST WRITE WINS simplest, loses data
silently, and clocks
disagree
VERSION VECTORS detect the conflict,
hand it to the app
CRDTs data types that merge
without conflict by
construction
APPLICATION MERGE domain rules decide
Last-write-wins is the default in many systems and is a data-loss policy. Worth knowing which one you have before it matters.
What to carry into ecommerce work
- Stock is the sharp case. Eventually consistent stock oversells. Decrement atomically in one authoritative place — Transactions and ACID
- Prices and content tolerate staleness well. Cache them hard
- Basket and account need read-your-writes, or they feel broken
- Analytics is eventually consistent by design. Two tools disagreeing at 10am and agreeing by midday is lag, not a bug — and it’s the first thing to rule out before investigating a discrepancy — Tool Discrepancies