What is eventual consistency, and when is it an acceptable tradeoff?
Quick Answer
Eventual consistency means that after a write, different replicas/nodes may temporarily disagree about the current value, but they're guaranteed to converge to the same value once no further writes occur and replication has had time to propagate. It's an acceptable tradeoff when brief staleness has low real-world cost (view counts, "likes," non-critical caches) but not for correctness-critical data where any window of disagreement is dangerous (account balances, inventory counts that must never oversell, security/permission checks).
Detailed Answer
What it means concretely
Client writes "likes = 101" to Replica A.
Replica A immediately has the new value.
Replica B and Replica C haven't received the replication update yet.
A read hitting Replica B right now might still return "likes = 100" --
temporarily inconsistent with Replica A's already-committed value.
Given enough time (milliseconds to seconds, typically), replication
catches up, and B and C converge to "likes = 101" too.
This is the AP side of the CAP theorem in practice: rather than blocking the read (or the write) until every replica agrees (which would sacrifice availability/latency), the system accepts reads that might be momentarily stale, trusting that convergence happens shortly afterward.
When it's a fine tradeoff
- Social media counters (likes, view counts, follower counts) — a few seconds of staleness or a slightly-off count is invisible/irrelevant to users, and the alternative (blocking every like/view to synchronously update every replica) would add unacceptable latency at massive scale for negligible correctness benefit.
- Non-critical caches — a cache that's occasionally a few seconds stale is, by definition, an acceptable tradeoff (that's the whole premise of caching).
- Content/CDN distribution — a page update propagating to edge servers over a few seconds/minutes is standard and expected.
- DNS — the textbook example of eventual consistency at internet scale: DNS record changes propagate over time (per TTL), and the world briefly seeing old vs. new records simultaneously is an accepted, designed-for tradeoff.
When it's dangerous
- Financial balances/ledgers — reading a stale balance and allowing a withdrawal based on it can produce genuine financial loss (overdraft that shouldn't have been allowed).
- Inventory that must never oversell — two replicas both believing "1 item left" and both allowing a purchase results in overselling.
- Security/permission checks — a stale "user has access" read could grant access that was just revoked, a real security gap.
- Uniqueness enforcement — two concurrent writes on different replicas, both believing a username is available, can both succeed, violating a uniqueness invariant the business actually depends on.
The skill being tested isn't "know the definition" — it's being able to reason about which specific pieces of data in a system can tolerate eventual consistency and which genuinely can't, and choosing a storage/consistency strategy per data type accordingly (e.g., storing account balances in a strongly-consistent store while storing view counts in an eventually-consistent one, even within the same overall application).