A user saves their profile, the page reloads, and the old name is back. What is happening and how do you fix it?
7 min readUpdated 2026-08-15
0
Answer
Short answer
The write committed on the primary and the reload was served by a replica that had not applied it yet. Fixing it means giving that session a read-your-writes guarantee, either by routing its reads to the primary for a bounded window or by carrying the commit position and refusing to read a replica behind it.
Was this answer helpful?
Likely follow-ups
→Two consecutive reads hit two replicas at different positions. What does the user see, and what is that guarantee called?
→The write and the read happen on two different devices. Which of your fixes still works?
→How would you monitor lag so that this is caught before a user reports it?
→A comment is visible but the post it replies to is not. Which guarantee did you violate?
Asynchronous replication acknowledges a write once the primary has it durably, then streams it to replicas. So there is a window, usually milliseconds and occasionally minutes, during which the primary and a replica disagree, and a read routed to a replica inside that window legitimately returns the old value. Nothing is broken and no data is lost — the read is correct with respect to a state that was true a moment ago.
The reason this surfaces as a bug report rather than as a metric is that the user performed the write. Staleness is invisible when you are reading somebody else's data and glaring when you are reading your own, because you know what the value should be. That asymmetry is the whole insight: the guarantee you need is not global recency, it is a per-session promise that a client never sees a state older than one it has already caused.
That guarantee has a name — read-your-writes, one of the session guarantees, alongside monotonic reads, monotonic writes and writes-follow-reads. Naming it matters because it tells the interviewer you are proposing something far cheaper than linearisability. You are not making every read see the latest write from every client; you are making one client's reads consistent with its own history, and that can be done without a single extra round trip between replicas.
Loading diagram…
The thing to look at is the difference between the two stream arrows: the replicas are at different positions at the same instant, so "read from a replica" is not one behaviour, and any fix that does not consult a specific replica's applied position is guessing.
The three fixes, in ascending order of cost and correctness
Route the session's reads to the primary for a window. After a write, mark the session — a flag with a short expiry in a shared store, or a signed cookie — and send its reads to the primary until the flag lapses. Simple, correct, and it works today. The cost is load: if 5 percent of requests are writes and each pins the session to the primary for 10 seconds, you have moved a share of read traffic onto the one node you were offloading, and that share grows with how write-heavy the workload is. Choose the window from your observed replication lag, and understand that you have coupled correctness to a timeout — if lag exceeds the window you are back to the original bug, silently.
Narrowing the pinning helps a lot. It is rarely the whole session that needs the primary, just reads of the objects the session wrote, so pin per entity rather than per user where you can distinguish them.
Sticky routing to one replica. Send a session's reads consistently to the same replica. This is cheap and buys you monotonic reads, which is a genuine improvement, but it does not buy read-your-writes: the replica you are stuck to may be the lagging one. It also fails when that replica is removed from rotation, at which point the session moves to a replica that may be behind the one it was reading, and time appears to run backwards. Useful as a supporting measure, wrong as the primary answer.
Carry the commit position. The correct mechanism is to make the client's causal history explicit. The write returns the log position at which it committed; the client carries that token; a read presents it, and the read is only served by a replica whose applied position is at or beyond it, waiting briefly or falling back to the primary otherwise. This is exact rather than probabilistic, it costs nothing when replicas are caught up, and it degrades into the first fix precisely when lag is the problem.
Some systems expose this directly. MongoDB's causally consistent sessions carry a cluster time, and a read can specify afterClusterTime so the server waits until it has applied at least that point. In PostgreSQL the pieces are there but the wiring is yours: pg_current_wal_lsn() on the primary gives you the write position, pg_last_wal_replay_lsn() on a standby gives you its applied position, and pg_wal_lsn_diff() compares them, so an application-level router can track each replica's position and route accordingly. What you must not do is compare wall-clock timestamps between machines and call it a position; clock skew makes that a source of subtle, unreproducible staleness rather than a fix for it.
The second anomaly, which is the one that gets missed
Read-your-writes only covers state the session itself created. There is a distinct failure with no write in it at all: two consecutive reads land on two replicas at different positions, so the second read returns an older state than the first. A count decrements, an item reappears in a list after being seen gone, a page reloads to a previous version. That is a violation of monotonic reads, and it is arguably more confusing to users because there is no action of theirs to explain it.
The fixes overlap but are not the same. Sticky routing solves monotonic reads and not read-your-writes. Position tokens solve both, if the client advances its token to the highest position it has observed, not merely the highest it has written. That distinction — tracking reads as well as writes into the causal token — is the difference between a design that handles the reported bug and one that handles the class.
The related third case is ordering across objects. A comment visible while the post it replies to is not means a causal dependency crossed a replication boundary in the wrong order, which is what writes-follow-reads addresses: a write made after reading some state must not become visible before that state does. This is the guarantee that matters when the two objects live in different partitions or different services, and it is the reason "eventual consistency is fine, users won't notice" is a claim that needs testing rather than asserting.
What to say about scope and about measurement
Two limits are worth volunteering. A session guarantee is scoped to the session, so a token in a cookie does nothing when the user writes on their phone and reads on their laptop; users perceive consistency per person, not per session, and closing that gap means holding the position server-side against the account, which starts to cost what you were avoiding. And these guarantees say nothing about two different users, so if user A writes and user B must see it — a chat message, an approval, a transferred balance — you need a stronger model and should say so rather than stretching a session guarantee to cover it.
On measurement: lag must be monitored per replica and as a distribution, not as a fleet average, because the average hides the one standby that is minutes behind and serving a share of your reads. Watch it in both units. Byte lag tells you how much data is outstanding, which detects a network or disk bottleneck; time lag tells you how stale a read can be, which is the number your window is set from. An idle primary makes byte lag zero while a stalled replay leaves time lag large, and an alert on only one of them misses that. Then set the alert threshold below the pinning window you chose, so the first symptom is a page rather than a support ticket.
Seniority Level Calibration
Mid-Level (L4/L5): Blames browser caching or proposes routing all read traffic to the primary database, negating the purpose of read replicas.
Senior (L6): Identifies replication lag as the root cause, designs temporary primary read-pinning windows (cookie/session), and explains Monotonic Read violations.
Staff / Principal (L7+): Implements LSN/WAL commit-position tokens (afterClusterTime / pg_current_wal_lsn), designs multi-device session token sync, and monitors per-replica byte lag vs time lag distributions.
What this failure looks like in the wild
In October 2018, GitHub lost connectivity between two data centres for 43 seconds, and the MySQL clusters on either side of the partition each went on accepting writes, leaving roughly a day of degraded service while the diverged records were reconciled. It is worth carrying into this question because it shows the far end of the same asynchronous replication that produces a lag window: a replica that can serve a stale read is also a replica that can be promoted while holding an incomplete view of the log. An interviewer will want you to name which reads you are willing to serve from a replica, and what you do once the replica set has stopped agreeing on what was written at all.
Ask which guarantee the user's complaint actually violates before choosing a mechanism. "Save then reload shows the old value" is read-your-writes; "refresh shows an older value than the previous refresh" is monotonic reads; and the sticky-routing fix that solves the second does nothing for the first.