Consistency & Transactions

Read-Your-Writes Consistency

Also known as: read-after-write consistency, session consistency

Definition

Read-your-writes consistency guarantees a client always sees its own completed writes, even while other clients may still see stale data. It is a per-session guarantee, cheaper than global strong consistency, and it removes the class of bug where a user submits a change and the next page shows the old value.

Last reviewed · Part of the Architecture Glossary

In practice

Three implementations, in increasing order of sophistication:

  1. Read from the primary for N seconds after a session writes. Trivial, and it works — but it concentrates load on the primary and N is a guess.
  2. Write-token / LSN pinning. The write returns the log position it committed at; the client sends that token with the next read, and the router picks a replica that has applied it (or waits). This is what Aurora, Vitess and DynamoDB's session tokens do.
  3. Sticky sessions to one replica. Simple but fragile: rebalancing or a replica restart silently breaks the guarantee.

When it matters

Any post-write redirect — the "saved successfully" page, the comment that should appear in the thread, the profile that must show the name just entered. It is the difference between a system that is eventually consistent and one that feels broken.

Common mistake

Implementing it in the ORM's read-replica router but not in the search index or cache. The user updates a product, the row is correct on read-after-write, and the search results still show the old title for 30 seconds — the guarantee has to cover every store the read path touches.

See also

Go deeper