How it works
Start with the write authority and the copies readers use. A profile update might commit to a primary database while read replicas, caches, and a search index still contain the old name. Reads from those copies can return different answers until the update reaches them.
Propagate changes asynchronously through replication, change data capture, or durable events. For example, a committed review update produces an event that updates the restaurant's rating summary and search document. A transactional outbox or database change stream avoids losing the update between the database commit and event publication.
Make propagation survive failures. Consumers need retries, durable progress tracking, and idempotent updates; replicas may need background repair to find missed changes. Eventual consistency is a convergence guarantee under those recovery assumptions, not a promise that data becomes correct merely because time passes.
Handle concurrent or out-of-order updates explicitly. A search consumer can reject document version 41 after applying version 42. Systems accepting writes at multiple replicas also need a conflict policy, such as deterministic last-write-wins, application-level merging, or a suitable CRDT; timestamp-based policies can discard valid concurrent changes.
Define what readers experience before convergence. Eventual consistency alone does not guarantee read-your-writes, monotonic reads, or a maximum delay. You can add session routing or version tokens so a user sees their own update while other users still read asynchronously updated copies.
Choose consistency per operation rather than for the whole product. A hotel search index can show stale availability, but the reservation write must atomically verify inventory. Strong consistency, commonly meaning linearizability in this comparison, makes operations appear to take effect in a single order that respects real time; eventual consistency does not require that immediate agreement.
A worked example
A like count that catches up without losing updates
Suppose a post displays 10,000 likes. The service atomically changes a user's authoritative like state from absent to present and records an outbox event in the same transaction. The API confirms the like immediately; the public total may still show 10,000. A consumer applies the event once and publishes 10,001. If the user quickly unlikes, the unlike event carries a higher per-user, per-post version. The consumer tracks the last applied state and version, adjusting the total only for an accepted state transition. Duplicate or older events cannot inflate the count or undo the unlike. The UI can show the user's own state immediately while the shared total catches up. Monitor consumer lag and reconcile aggregates against authoritative state after processing failures.
Trade-offs to say out loud
- Less coordination on the request path
- Asynchronous propagation can keep replica or index updates out of foreground latency, but moves work into queues, consumers, and recovery processes.
- Availability during partitions
- Replicas can keep serving some reads or accepting independent writes during a partition, but cannot also guarantee that every operation observes one current, globally agreed state.
- Stale user-visible results
- Users may see an old profile, missing post, or outdated count, so the design needs an explicit freshness target and behavior when that target is missed.
- Conflict resolution can lose information
- A deterministic winner makes replicas agree, but policies such as last-write-wins may discard changes that the application needed to preserve.
- Recovery becomes part of correctness
- Retries, replay, repair, version checks, and deletion handling must ensure that missed or reordered updates do not leave copies permanently wrong.
- Strict invariants need separate enforcement
- Scarce inventory, exclusive assignments, and spendable balances usually require an authoritative atomic decision or carefully allocated rights rather than independently accepted eventual updates.
When to reach for it
- The prompt includes feeds, search indexes, rating summaries, or counters where temporary staleness is acceptable.
- Read-heavy traffic benefits from replicas or caches, and the product can define which reads may lag.
- Several derived views must update after one authoritative database write without blocking that write on every downstream service.
- A multi-region or offline-write requirement favors continued operation during disconnection, and the application has a defensible conflict-resolution policy.
- Different operations have different correctness needs, such as stale hotel search results followed by an authoritative inventory check at booking.
How to bring it up in the interview
- Name the exact stale surface: 'The like total is eventual, but each user's like state is authoritative.' Interviewers will probe whether stale data can break an invariant.
- Describe the full convergence path: database commit, durable change capture, consumer application, retries, and repair. Be ready to explain a crash between any two steps.
- State a proposed freshness target, how you measure it, and what happens during a prolonged outage. Distinguish a normal operating target from a guaranteed upper bound.
- Walk through duplicate delivery, out-of-order updates, concurrent writes, and deletion. Explain which versions or merge rules prevent old data from overwriting newer state.
- Compare alternatives concretely: read from the leader for a critical decision, use a session version for read-your-writes, or accept lag on a public count. Expect questions about the added latency and failure behavior.
Common mistakes
- Saying 'it will be consistent in a few seconds' without a propagation mechanism, recovery path, or explicit bounded-staleness guarantee.
- Treating strong versus eventual consistency as a SQL-versus-NoSQL choice instead of an operation-level contract.
- Using an eventually consistent count or cached balance to authorize a scarce-resource allocation.
- Assuming eventual consistency provides read-your-writes, monotonic reads, or preservation of every concurrent update.
- Assuming a queue, retry loop, or cache TTL alone guarantees convergence while ignoring lost events, reordered updates, and deleted records returning.
Where it comes up
Interview questions where eventual consistency is part of a strong answer, and why.
- Design a distributed key-value storeAvailable writes during partitions require explicit conflict resolution, repair, and deletion handling so replicas eventually converge.
- Design a news feed like FacebookAsynchronous fan-out creates lagging feed views that must catch up reliably after retries and worker failures.
- Design Facebook likes at scaleThe design must separate authoritative like state from asynchronously aggregated totals while preserving exact eventual counts.
- Design Facebook post searchSearch indexes lag authoritative posts, requiring versioned updates and current permission checks despite stale indexed content.
- Design a restaurant review app like YelpReview edits and deletions must converge correctly across rating aggregates, caches, and search documents.
- Design Facebook MarketplaceListing updates propagate asynchronously into discovery indexes while current listing state remains authoritative.
- Design Dropbox or Google DriveOffline edits and delayed change delivery require conflict handling and reliable convergence across devices.
- Design an ad click aggregatorLive aggregates must incorporate retries and late events before reconciliation produces complete billing totals.
Questions people ask
What is the difference between strong consistency and eventual consistency?
Strong consistency, usually meaning linearizability in this comparison, makes each operation appear to occur atomically in an order that respects real time. Eventual consistency permits temporary disagreement but requires convergence once updates stop and propagation completes. Neither term by itself specifies durability or multi-record transaction guarantees.
How long does eventual consistency take?
Eventual consistency alone specifies no time limit. Convergence depends on replication lag, queue backlog, network failures, and repair progress. If the product needs updates visible within a fixed interval, define a separate bounded-staleness contract and decide whether to wait, reject, or use an authoritative read when it cannot be met.
How do you make an eventually consistent system converge?
Use reliable change propagation, retry-safe application, and a consistent policy for concurrent or reordered updates. Retain enough version and deletion information to prevent stale data from returning, and provide replay or repair for missed changes. Eventual consistency does not necessarily imply lost writes; whether acknowledged writes survive failures depends on the durability design.