LESSON 16.4
Session guarantees in practice
Implementing read-your-writes, monotonic reads and causal consistency on top of lagging replicas, with sticky routing, replication positions and version tokens.
6 min read
The previous lessons named consistency guarantees. This one is about building them: how a system that reads from lagging replicas can still give each user a view that makes sense.
The anomalies, briefly
- Read-your-writes broken
- I saved, refreshed, and my change is gone
- Monotonic reads broken
- I refreshed and older data came back
- Causal order broken
- I see a reply but not the message it answers
All three appear with asynchronous replicas and disappear if every read goes to the primary. The goal is to fix them while still using replicas for most reads.
Read-your-writes
Three implementations, from simplest to most precise:
- Read from the primary for a while after writing. After a user writes, route their reads to the primary for, say, 10 seconds (tracked in a cookie or session). Easy, and good enough for many apps.
- Primary for the user's own data. Profile pages read the owner's own profile from the primary and everyone else's from replicas.
- Replication position tokens. The write returns the primary's log position (an LSN in Postgres, a GTID in MySQL). The client sends it with later reads, and the router picks a replica that has replayed past it, waits briefly, or falls back to the primary.
Position tokens are precise: they ask for exactly "caught up to my write", nothing more. Many databases and proxies support them directly; DynamoDB and Cosmos DB expose similar session tokens.
Monotonic reads
Users shouldn't see time go backwards. Two ways:
- Sticky replicas: hash the user id to choose a replica, so each user's reads always hit the same one. If that replica fails, the user moves and may see a small jump.
- High-water mark: the client remembers the highest position it has seen, and every read asks for at least that. This is the same mechanism as read-your-writes, applied to reads too.
Causal consistency
Causal consistency means effects never appear without their causes: a reply without its question, a permission change applied after the document it was meant to protect.
Within one leader-based database it comes almost free, since the log orders everything. Across partitions or regions, writes carry their dependencies (a version vector or the position the writer had seen), and a replica delays showing a write until its dependencies are there. That's more machinery, so systems apply it where order matters to users: comments, messages, permissions.
Choosing per operation
Not every read needs the same guarantee. A product catalog can be seconds stale. A user's own cart needs read-your-writes. An account balance before a withdrawal needs the primary. Deciding per operation keeps most reads cheap while protecting the ones users notice.
Try it
Shared Document Revision Service HLD
Make sure authors always see their own latest revision.