Read Your Writes
A consistency guarantee that after a user performs a write, their subsequent reads will always reflect that write. Without it, a user might save data and see the old version.
What is Read Your Writes?
In short
Read-your-writes consistency is a guarantee that once a process successfully completes a write, every later read from that same process returns that write or something newer, never an older value. It prevents the surprise where you save a change, reload the page, and see the version from before you saved.
What it is
Read-your-writes consistency, sometimes called read-your-own-writes or the read-after-write guarantee, is a session-level consistency model. It promises one specific thing: after a client writes a value, any subsequent read issued by that same client will see at least that value, never an older one.
It is deliberately narrow. It says nothing about what other users see, and nothing about ordering of unrelated writes. It only ties a single client's reads to that client's own prior writes. That is why it falls under the umbrella of client-centric or session consistency rather than strong consistency.
The model exists because most systems that scale reads do so by replicating data across many nodes. Replication takes time. A client can write to one replica and then, milliseconds later, read from a different replica that has not received the update yet. The result is stale data and a confusing user experience. Read-your-writes closes exactly that gap for the writer.
How it works under the hood
The hard case is a system with one primary that accepts writes and several read replicas that lag behind by anywhere from a few milliseconds to several seconds. A naive load balancer sends each read to whatever replica is closest or least busy, so a read right after a write often lands on a replica that has not caught up.
The simplest fix is sticky reads: route a user's reads to the same node, or to the primary, for a short window after they write. Many setups read from the primary for a few seconds following any write by that session, then fall back to replicas. This is cheap but concentrates load on the primary.
A more precise approach uses version tracking. When a client writes, the server returns a logical timestamp or log position, for example a PostgreSQL LSN or a DynamoDB sequence token. The client stores that marker and includes it on the next read. A replica only serves the read if it has applied changes up to that marker, otherwise it waits or the request is routed to a node that has. MySQL exposes this through GTID-based replica waits, and some drivers automate the whole loop.
A third option is to read from a quorum. If writes go to W replicas and reads consult R replicas out of N total, and you pick W plus R greater than N, every read overlaps at least one replica that holds the latest write. This is how Cassandra and DynamoDB-style systems can offer read-your-writes when you choose the right consistency level per request.
When to use it and the trade-offs
Reach for read-your-writes whenever a user takes an action and then immediately looks at the result: editing a profile and reloading it, posting a comment and seeing it appear, updating an account setting, or completing a checkout and viewing the order. In all of these, showing stale data right after the user's own change feels broken even if it self-corrects a second later.
The trade-off is cost and complexity. Routing reads to the primary or to a quorum reduces how much you benefit from cheap, scalable replica reads. Version-tracked reads add latency when a replica has to wait to catch up, and they require the client and driver to carry the version marker correctly across requests.
It is also weaker than it sounds, which is usually fine. It does not promise other users see your write quickly, and it does not order your writes against anyone else's. If you need that, you are looking at monotonic reads, causal consistency, or full strong consistency, each of which costs more. Many products combine read-your-writes for the writer with eventual consistency for everyone else, which gives a good experience cheaply.
A concrete example
Imagine a social app where you update your display name. The write goes to the primary database in one region. Your profile page then issues a read that the load balancer happens to send to a read replica in another region that is 800 milliseconds behind. Without read-your-writes, the page shows your old name and you assume the save failed, so you click save again and create duplicate writes.
With read-your-writes, the write returns a log position. Your client attaches that position to the profile read. The replica checks whether it has applied up to that position; if not, it briefly waits or the request goes to the primary. Either way, you see your new name, and the rest of the world catches up through normal replication a moment later.
AWS made this an explicit knob. A DynamoDB Query or GetItem defaults to eventually consistent reads, which are cheaper and may miss a just-completed write. Passing ConsistentRead set to true gives a strongly consistent read that always reflects your prior write, at higher cost and only from the primary region. That single flag is read-your-writes in practice.
Where it is used in production
Amazon DynamoDB
Reads default to eventually consistent, but setting ConsistentRead to true guarantees a read reflects the caller's most recent write.
PostgreSQL
Apps route reads to the primary or wait on a replica's applied LSN so a user sees their own commit immediately after writing.
MySQL
GTID tracking lets a read wait until a replica has applied the session's last write before serving it, giving read-your-writes from replicas.
Apache Cassandra
Choosing a per-query consistency level where writes plus reads exceed the replica count makes a read overlap the latest write.
Frequently asked questions
- Is read-your-writes the same as strong consistency?
- No. Strong consistency means every reader, anywhere, sees the latest write immediately. Read-your-writes only promises that the writer sees their own write on later reads. Other users can still see stale data for a while, which makes it cheaper to provide.
- Why would a database ever not show me my own write?
- Because scaled systems replicate data across many nodes and replication lags. You write to the primary, then your next read may land on a replica that has not received the update yet, so it returns the old value until it catches up.
- How do I get read-your-writes without overloading the primary?
- Use version-tracked reads: capture the write's log position or sequence token, send it with the next read, and let any replica that has applied up to that position serve the request. Only fall back to the primary when no replica is caught up.
- Does read-your-writes guarantee my reads stay consistent over time?
- Not by itself. It only ties reads to your prior writes. If you also need reads to never go backward in time across requests, you want monotonic reads, which is a separate session guarantee often paired with read-your-writes.
- What happens to read-your-writes when a user switches devices?
- It can break if the guarantee is tied to a single connection or sticky session. To preserve it across devices, the version marker has to live with the user's identity or session token, not just one TCP connection or one server.
Learn Read Your Writes hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
Strong Consistency
A guarantee that after a write completes, all subsequent reads will return the updated value. Safer but slower than eventual consistency.
Session
A way to maintain state across multiple HTTP requests. The server stores data about a user and gives them a session ID (usually in a cookie).
Linearizability
The strongest consistency guarantee: every operation appears to take effect atomically at some point between its invocation and completion. As if there's a single copy of the data.
Serializability
A guarantee that concurrent transactions produce the same result as if they were executed one at a time in some serial order. The gold standard for database transaction isolation.
Snapshot Isolation
A consistency level where each transaction reads from a consistent snapshot of the database taken at the transaction's start time. Prevents dirty reads without full serializability overhead.