You move a user profile service to eventual consistency and support tickets start arriving: users update their name and the old one is still shown. Fix it without abandoning the architecture.

What the interviewer is testing

Whether you know that consistency is per-operation rather than per-system, and whether you reach for a targeted guarantee instead of a global one.

The reasoning

The complaint is not that the system is eventually consistent. It is that a specific, highly-visible interaction — I changed something and it did not change — violates the user's model of causality. Other users seeing the old name for two seconds generates no tickets at all.

So the fix should be scoped to that interaction, not applied globally.

Read-your-writes guarantees a session sees its own updates. Implementations, roughly in order of cost:

• Sticky routing after write. For a short window after a write, route that session's reads to the primary. Simple, effective, and costs a small amount of primary read load.
• Write-through to the session. Return the updated entity in the write response and have the client render from it. Almost free, and it handles the most common case — the page you land on immediately after saving.
• Version tokens. The write returns a version; subsequent reads pass it, and a replica behind that version either waits or forwards to the primary. This is the most correct and the most work; databases such as DynamoDB and Cosmos DB expose it directly.

Why not the alternatives

Strong consistency everywhere discards the availability and latency the architecture was adopted for, to fix one interaction.

Bigger replicas reduce average lag but do not bound it, so the bug becomes rarer and harder to reproduce rather than fixed. Rare correctness bugs are worse than frequent ones.

A staleness warning is asking users to absorb an engineering problem, and it does not stop the tickets.

What a strong answer adds

Naming the related guarantee, monotonic reads — a session must never see time move backwards, which happens when consecutive reads hit different replicas with different lag. Session stickiness fixes both, which is why it is the usual first move.

Also: measure and alert on replication lag as an SLI. Without it, the failure is invisible until users report it.