After a user updates their profile, the page sometimes shows the old value. The team says this is normal eventual consistency. Is that acceptable?

What the interviewer is testing

Whether you know that session guarantees are separable from the global consistency model, so this is a fixable defect rather than an inherent cost.

Why it is not acceptable

A user must always see their own writes. Its absence produces the most alarming class of eventual-consistency bug: the user updates, the page reloads, the old value appears, so they update again. Now there is a support ticket and a belief that the system loses data.

Users tolerate seeing other people's changes late. They do not tolerate their own change disappearing, because it reads as data loss rather than as staleness.

The mechanism

The write goes to a primary; the subsequent read is load-balanced to a replica that has not yet received it. Nothing is broken and the experience is indefensible.

The fixes

Read from the primary for a window after a write. Simple, and it concentrates read load.

Sticky routing to the replica that served the write.

Token-based — the write returns a version or log position, the client presents it on subsequent reads, and the replica waits or redirects until it has caught up. This is the most robust and is what mature distributed databases expose.

Optimistic client update, where the interface shows the new value locally after a successful write. Effective and it masks rather than fixes the problem, so it fails on a different device or after a refresh from a different replica.

The related guarantees worth naming

Monotonic reads — time must not appear to go backwards across successive reads, which happens when consecutive requests hit replicas at different positions.

Consistent prefix — causally related events must not be observed out of order, so a reply never appears before the message it answers.

These are session guarantees, and a system can provide them while remaining eventually consistent globally. That combination is usually the right target.

What a strong answer adds

The general design position: choose the weakest consistency model that preserves the user's mental model. Global strong consistency is expensive and usually unnecessary; session guarantees are cheap and cover almost all of the perceived correctness.

Common weak answers

Accepting it as inherent to the architecture. Switching to strong consistency globally, which is a large cost for a narrow problem.