Let people see their own writes

Here’s a bug that behaves like a ghost. A user posts a comment. The request succeeds — green check, the works. They refresh, and it’s gone. So they post it again. Now there are two. They email you, annoyed, maybe a little unsettled. You open the database expecting corruption and find… both comments, sitting there, perfectly intact. Nothing is broken. And yet something is very broken.

What happened is that you scaled reads the normal way: writes go to a primary database, and reads get spread across replicas that copy from the primary a beat later. That beat — replication lag, usually milliseconds, occasionally whole seconds under load — is invisible to almost everyone almost all the time. It becomes visible in exactly one situation: a user reads immediately after writing. Their comment landed on the primary. Their refresh happened to hit a replica that hadn’t caught up yet. The system is consistent — it will agree with itself soon enough — it’s just not consistent fast enough for the one person who literally just typed the thing.

The principle underneath: eventual consistency is a fine promise to make to the world and a terrible promise to make to the author. Everyone else can happily see your comment a second late; they’ll never know. You cannot bear to not see your own comment. The specific guarantee you need has a name — read-your-writes (a flavor of session consistency): a user always sees the effects of their own past writes, even while the rest of the system lags behind.

How you actually deliver it, cheapest first. Read from the primary for a short window after a write — pin this user’s reads to the primary for a few seconds after their last write, then let them drift back to replicas. Dead simple, a little extra primary load, solves the common case. Track a write token — record the primary’s log position at write time, stash it in the user’s session, and only serve their reads from a replica that has caught up to at least that position. More precise, more plumbing. Serve the just-written value from cache — hand the author their own fresh value out of a session/local cache while the replicas catch up. Sticky routing — keep a user’s requests on a path that reflects their writes, with eyes open, because sticky sessions bring their own failure modes.

The trap is treating this as a global database problem to solve once. It isn’t. Read-your-writes is a per-user, per-session promise, and it’s cheapest precisely when you scope it that tightly: don’t force the whole system into strong consistency (you’ll pay for that on every query, everywhere) — just guarantee that this user sees their writes for the brief window it matters.

And be deliberate about which surfaces need it. The author’s own view right after an action — post, edit, upload, settings change, profile update — needs read-your-writes. A global feed, a leaderboard, a stranger’s profile does not; eventual consistency is correct and cheaper there. Consistency isn’t one dial you set for the whole app. It’s a promise you make per read, to a specific person, about specific data.

Latency is a feature; so is freshness — but only where it’s felt. A user will forgive the world being a second behind. They will never forgive the app forgetting what they just did. Spend your consistency budget right there.

The concepts, to look up: read-your-writes and monotonic-reads / session consistency (Doug Terry’s session guarantees); replication lag; the broader map of consistency models (Jepsen). Distinct from the CAP trade-off (a theorem about what breaks during a partition) and from cache staleness.