Archiveconsistency
Read-Your-Writes Is a Product Requirement
Users notice when their own update disappears. Sticky sessions are a patch; version tokens are the fix.
- Published
- Reading time
- 1 min read
After a user saves a profile change, the next page load must show it. If reads can hit a lagging replica, that expectation breaks and the product feels broken.
Why it happens
Writes go to a primary; reads go to replicas with replication lag. The user's next request lands on a replica that has not applied the write. This is a consistency-model problem, not a bug in the database.
Fixes, weakest to strongest
- Sticky sessions: route a user to the same replica. Fragile behind load balancers and after failover.
- Read primary after write: correct but sends all post-write traffic to the primary.
- Version tokens: return the write's log position (LSN, timestamp) and require replicas to be at least that fresh for this session. CockroachDB and others expose this directly.
- Session consistency: the system tracks a per-session minimum timestamp and waits on replicas.
The design point
Read-your-writes is scoped to one user's session. It is cheap to provide if the client carries a token; it is expensive if you approximate it with global strong consistency.
Takeaway: return a freshness token on writes and honor it on reads. That is the smallest mechanism that satisfies the user's mental model.