How it works
Read-your-writes means that after a successful write, subsequent reads in the same session reflect that write or a later state that supersedes it. For example, after you save a profile name, refreshing should not return the name from before your save. This does not prevent another writer from changing the name afterward.
Monotonic reads means that once a session has observed some state, later reads do not return an earlier state. If a request sees document revision 12, the next request must not return revision 10 just because a load balancer chose a lagging replica. This guarantee matters even for users who never write.
Two other standard session guarantees cover write ordering. Monotonic writes preserves the order of a session's writes when they are applied. Writes-follow-reads ensures that a write is applied after the writes whose effects the session previously read; together, these guarantees help preserve causal dependencies within the session.
A practical implementation returns a version or commit-position token with each response. The client or a session service tracks the positions of successful writes and completed reads, then sends those requirements on later requests. A replica serves a read only after its applied position covers those requirements; otherwise, the service waits, routes elsewhere, or returns an explicit freshness error.
Tokens must match the storage system's ordering model. One log position can work within a single replication group, but independently replicated shards may require a vector of positions. Failover also requires lineage or epoch information so that two unrelated log positions are not treated as comparable.
Every serving layer must honor the requirement, including caches and materialized views. A database replica being current does not make an old cached response safe. Define the session boundary explicitly: one browser tab, one device, or an account across devices; broader boundaries require propagating or merging more state.
A worked example
Saving a wiki page through lagging replicas
A wiki stores one page on a leader with two asynchronous replicas. A successful save creates revision 42 at log position 8,200 and returns a token identifying the replication group, history epoch, and position. The browser includes that token when reopening the page. Replica A has applied through 8,190, so it cannot serve the request yet; replica B has applied through 8,205 and can. If the response shows revision 43 from another editor, that also satisfies read-your-writes. The browser records the newer response position to preserve monotonic reads. A cached revision 41 is rejected. If no eligible replica is reachable, the service waits briefly, then returns a freshness error rather than silently serving old content.
Trade-offs to say out loud
- Freshness can cost latency or availability
- If reachable replicas have not caught up, preserving the guarantee requires waiting, routing to a suitable replica, or failing rather than returning stale data.
- Leader reads increase load and geographic latency
- Routing session reads to the current leader is simple for a single replication group, but reduces replica offloading and may add cross-region round trips.
- Session metadata grows with scope
- Tracking dependencies across shards, devices, and services can turn a small token into a larger context that needs safe merging and bounded storage.
- Sticky routing is useful but insufficient
- Staying on one replica can preserve monotonic reads while its history remains intact, but does not by itself ensure that replica has seen the session's writes.
- Derived views need separate handling
- Search indexes, feed caches, and other asynchronous views must prove they include the required updates or use an explicitly narrower consistency contract.
- Session guarantees do not protect global invariants
- They do not prevent double booking, lost updates, or overspending, which require suitable concurrency control and transaction semantics.
When to reach for it
- A user saves a document, review, or listing and expects the next read to show the saved change.
- Reads are distributed across asynchronous replicas or regions, and refreshing must not make previously observed state disappear.
- Clients reconnect or switch serving nodes, but document revisions, message history, or source sequence numbers must not move backward.
- The product can tolerate stale data for other users while giving the writer a stronger experience.
- A design includes asynchronous search or materialized views, and the interviewer asks exactly what users see immediately after an update.
How to bring it up in the interview
- Start with a user-visible contract: 'After a successful save, this device's document reads must include that save; other users may briefly see an older revision.' Specify which endpoints and devices the contract covers.
- Separate read-your-writes from monotonic reads: the first tracks the session's writes, while the second also tracks state learned by reading other users' writes.
- Describe the mechanism concretely: return a commit token, propagate it on requests, and check a replica's applied position before serving. Expect questions about multiple shards, failover, and token loss.
- State the failure policy before claiming a guarantee. Explain how long you wait, where you can reroute, and what response the user receives when no eligible replica is reachable.
- Walk through caches and derived views separately. Interviewers may ask whether an optimistic UI merely hides stale reads, whether a search index honors the token, and how two devices share session state.
Common mistakes
- Calling read-your-writes linearizability: it constrains one session's observations, not the real-time ordering of all clients' operations.
- Assuming a fixed delay after writing is a guarantee; replication lag can exceed the delay during overload or failures.
- Treating replica affinity as sufficient without checking write visibility, replica restarts, or failover.
- Using one timestamp or the maximum position from unrelated shards as a universal freshness token without proving that it captures all required dependencies.
- Equating monotonic reads with increasing field values; a valid newer balance, price, or counter can be lower than an older one.
Where it comes up
Interview questions where read-your-writes and session guarantees is part of a strong answer, and why.
- Design a distributed key-value storeSession tokens and replica eligibility make the consistency contract concrete across replication lag, partitions, and ownership changes.
- Design Wikipedia or NotionA successful document save must remain visible to its author despite global caches and asynchronous read replicas.
- Design a restaurant review app like YelpAuthors need to see their review edits while restaurant pages, rating aggregates, and search results update asynchronously.
- Design Facebook MarketplaceListing updates need an explicit writer-visible contract across the source database, caches, and asynchronous search index.
- Design a real-time stock price feedMonotonic reads become central when reconnecting through lagging regions must not roll an observed source sequence backward.
Questions people ask
What is the difference between read-your-writes and monotonic reads?
Read-your-writes ensures later reads reflect your own successful writes or later updates that supersede them. Monotonic reads ensures you do not go backward from state you already observed, even if someone else wrote it. A session can need both guarantees.
Can an eventually consistent database provide read-your-writes?
Yes. The system can offer stronger reads for a particular session by routing to an eligible replica or waiting until that replica has applied the session's writes. Other sessions may still read stale data, and maintaining the guarantee during failures may require rejecting some reads.
Do sticky sessions guarantee read-your-writes consistency?
Not by themselves. A sticky read replica might still lag behind the leader that accepted the write, and reconnects or failover can change the serving replica. Affinity can help, but a robust design also checks write visibility and carries session requirements across routing changes.