Eventual Consistency

In technical terms

The guarantee is convergence, not freshness. Sharpenings are priced individually: monotonic reads (never see older after newer), read-your-writes (pin to primary or version token after write), session causality, and causal ordering. Cross-region replication adds seconds the user can observe.

Why it appears in interviews

Any design with replicas, caches, or async roll-ups forces a staleness decision, and interviewers listen for the user-visible consequence: “your profile edit may not show for 2 seconds on the other region’s cluster” is the sentence that shows lived experience.

The common misconception

“Eventual” does not mean “eventually correct”: conflicting writes are resolved by policy. Last-write-wins can silently lose an update. And it does not apply everywhere it is tempting: balances, inventory claims, and lock registries need strong paths or compensating constraints.

Trade-offs & when it hurts

Strong consistency costs availability (quorum unreachability refuses service) and latency (the slowest ack gates the write); eventual buys speed and scale at the cost of a UI contract. Staleness budgets, optimistic badges, or merge UX. Name the budget the product chose, not just the model.

How to show it in an interview

Convert the concept into a budget: “Feeds tolerate 2 seconds of replica lag. Nobody reads their own post in a list; balances read from the strongly consistent store. The money answer must never be almost right. After any write I pin the user to primary for 60 seconds so the confirmation page is never empty.” Two data paths, two different guarantees, named like that, is the answer.

Questions this concept earns

• A user posts a comment and it vanishes on refresh: what broke and what is the fix?
• Which of your screens can serve stale data, and which physically cannot? Defend each line.
• The region partition means no quorum write. What does the product do: block, queue, or serve stale?

Related