We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Consistency Models
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Read Your Writes across a run of lessons, not one page. These 4 alone are about 77 minutes of step-by-step reading, every one with a quiz.
You always see your own updates immediately, the consistency users expect but rarely get by default.
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee.
If A causes B, everyone sees A before B, preserving cause-and-effect in distributed systems.
All nodes see operations in the same order, though not necessarily real-time order.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Read-Your-Writespay once,
yours for life
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.
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 (log sequence number) or a MySQL GTID (global transaction id). 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.
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.
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.
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.
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.
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.
Use version-tracked reads: capture the write's log position, 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.
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.
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.
The industry examples in “The next question”:
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.
This page explains the idea. The "Read-Your-Writes" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Read-Your-Writes lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Read Your Writes in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
