Read-Your-Writes Consistency: Why Your Profile Update Disappears on Refresh

The bug report sounds simple. A user updates their profile photo. The server returns 200 OK. The user refreshes. The old photo is back. Engineering closes it as "cannot reproduce" because by the time they look, the new photo is there.

There is no race in the form. There is no caching layer at fault. The bug is replication lag, and the cure is not "make the database consistent." It is read-your-writes, which is narrower and cheaper than full strong consistency.

Here is the shape of the system. Writes go to the primary. Reads fan out across read replicas to spread load. Replication is asynchronous: the primary acknowledges the write before the followers have it. Most of the time the followers catch up within tens of milliseconds. Sometimes, after a GC pause or a network blip, the gap is seconds. Your user's next request lands on a replica that does not yet have their write, and the API returns the previous value.

From the user's perspective this is broken. They just wrote it, the server said yes, and now it is missing. Other users seeing the old value for another half second is acceptable. The user who wrote it seeing the old value is not.

Four fixes, in order of operational cost.

One. Pin the user to the primary for a short window after a write. Stick a flag in their session: "last_write_at: T." For the next N seconds, route all of their reads to the primary. After that, they go back to followers. This handles the common case with one cookie and no database changes.

Two. Use version tokens. The write returns a version (an LSN, a logical timestamp, a Lamport clock). The client sends that version on subsequent reads. The router picks any replica whose applied position is at or beyond that version. This is what Spanner and DynamoDB call session consistency. It costs a little client state and a lot of replication-lag headroom.

Three. Always read from the primary, but only for "your own" data. The user's profile, their cart, their settings. Other users still see eventual consistency on that data, but the owning user sees their writes. Cheap to implement, blunt about which queries it covers.

Four. Lengthen the write-to-read gap by hiding the read. After the write succeeds, the client uses the response body to render the new state instead of refetching. The follower has time to catch up before the user clicks refresh. Free, but only works for screens you control.

The production failover bug that follows this one: the new primary is a former follower with replication lag of its own, and every session pin you wrote is now pointing at the wrong node. Pinning by node ID instead of role is the version of this fix that survives a failover.