Read-Your-Writes Consistency
also called Read-After-Write
A session guarantee that a client always sees its own updates, even when reads are served from replicas that may lag.
The cheapest fix to the most common user-visible symptom of eventual consistency: I changed my name and it still shows the old one.
Three implementations, in increasing order of cost and correctness. Sticky routing — for a window after a write, route that session's reads to the primary. Write-through to the client — return the updated entity in the write response and render from it, which handles the immediate case for almost nothing. Version tokens — the write returns a version, subsequent reads carry it, and a replica behind that version either waits or forwards; DynamoDB and Cosmos DB expose this directly.
The related guarantee is monotonic reads: a session must never see time run backwards, which happens when consecutive reads hit replicas with different lag. Session stickiness fixes both, which is why it is usually the first move.
The insight worth generalising: consistency is a property of an operation and a session, not of a system. Almost nobody needs global strong consistency; a great many people need this.