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 guarantee that once you read a value, subsequent reads will never return an older value. Prevents the disorienting experience of data appearing to go backward in time.
In short
Monotonic reads is a consistency guarantee that once a client has read a value, every later read by that same client returns either that value or a newer one, never an older one. It stops data from appearing to move backward in time, so a user who has already seen an updated profile never sees the stale version again on a refresh.
In short
Monotonic reads is a consistency guarantee that once a client has read a value, every later read by that same client returns either that value or a newer one, never an older one. It stops data from appearing to move backward in time, so a user who has already seen an updated profile never sees the stale version again on a refresh.
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 Monotonic Reads across a run of lessons, not one page. These 4 alone are about 84 minutes of step-by-step reading, every one with a quiz.
Once you have seen a value, you never see an older one, the minimum useful consistency guarantee.
Writes from a single client are applied in order, preventing write reordering across replicas.
Ensuring new versions work with old clients, old data formats, and old APIs without breaking existing consumers.
Careful per-row invalidation served more than twice the stale reads of doing nothing, because it raised the hit rate on the entries it cannot see.
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 Monotonic Readspay once,
yours for life
Monotonic reads is one of the session consistency guarantees defined for distributed systems. The rule is narrow but precise: within a single client session, reads progress forward in time. If you read version 5 of a record, no future read in that session can return version 4, 3, or anything older. It can return version 5 again, or version 6, or version 10, but never something staler than what you already saw.
It is important that this is a per-client guarantee, not a global one. Two different users can be looking at different versions of the same record at the same moment, and that is allowed. Monotonic reads only promises that any one client never witnesses time running backward for itself.
This is weaker than strong consistency. The system does not promise you see the latest write the instant it happens. It only promises you never regress. That makes it cheap enough to offer in systems that replicate data across many machines and regions, where strong consistency would be slow or impossible.
The disorienting backward-in-time effect happens because of replication lag. A write lands on one replica, and copies fan out to other replicas asynchronously. If your first read hits an up-to-date replica and your second read hits a replica that has not caught up yet, you see the old value. Monotonic reads exists to close that hole.
The most common implementation is sticky routing. The system pins a client session to a specific replica, often by hashing the user id or session token to a server. As long as you keep reading from the same replica, and replicas only move forward, you can never see an older value than before. Many CDNs and read-replica setups use this approach.
A more flexible technique attaches a version marker to the client. After a read, the server hands back a logical timestamp or version token, and the client sends it along on the next read. The receiving replica must serve data at least as fresh as that token, blocking or rerouting if it is behind. Azure Cosmos DB uses a session token like this so a client can move between replicas and still keep its reads monotonic.
Reach for monotonic reads when stale data is tolerable but going backward is not. A common case is a user editing their own settings or seeing their own comment appear: they can accept a few seconds of lag on the global state, but seeing their just-saved change vanish on the next refresh feels like a bug and erodes trust.
The cost of sticky routing is that load balancing gets less even and failover gets harder. If the replica a session is pinned to goes down, the client may briefly violate the guarantee or has to be carefully migrated forward to a replica that is at least as current. Token-based approaches avoid the pinning problem but add latency when the chosen replica is behind and the read has to wait or reroute.
Monotonic reads is often combined with read-your-writes consistency, which is a separate guarantee that you always see your own writes. The two together cover most of what users intuitively expect from a session, while still being far cheaper than full linearizability. They do not, however, guarantee anything across two different users.
Imagine you post a review and a friend likes it, pushing the like count to 1. You refresh and see 1 like, served by a replica in your region that has the update. A moment later you refresh again, this time routed to a replica in another region that has not received the like yet. Without monotonic reads you would see 0 likes, which looks like the like was undone.
With monotonic reads in place, that second refresh either gets routed back to a replica that already shows 1, or it carries a version token that forces the far replica to wait until it has caught up. Either way the count you see never drops from 1 back to 0.
This is exactly the kind of small, confidence-shaping correctness that large platforms care about. The underlying data is still eventually consistent across the globe, but each individual person experiences a timeline that only moves forward.
Amazon DynamoDB
Eventually consistent reads can lag, so clients use session tokens and consistent-read options to keep a session from observing older values after a newer one.
Azure Cosmos DB
Offers a named Session consistency level that bundles monotonic reads with read-your-writes using per-session continuation tokens.
MongoDB
Causally consistent sessions use operation and cluster timestamps so reads in a session never go backward, even when routed across replica-set members.
Cassandra and CDN read-replica tiers
Sticky routing pins a client to one replica or edge node so successive reads only ever move forward in version.
Monotonic reads says your reads never go backward in time once you have seen a value. Read-your-writes says you always see the effects of writes you yourself made. They are independent guarantees, and systems often provide both together inside a session because users expect both.
No. Strong consistency means every read returns the most recent write globally. Monotonic reads only promises that a single client never sees an older value than one it already read. You can still read stale data, you just cannot regress. It is a session-level guarantee layered on top of an eventually consistent store.
No, it is per client session. Two different users can legitimately see different versions of the same record at the same time. The guarantee only constrains the sequence of reads within one session.
Two common ways. Sticky routing pins a session to one replica so reads always come from the same forward-moving copy. Token-based versioning hands the client a logical timestamp after each read and requires the next replica to be at least as fresh as that token, rerouting or waiting if it is behind.
Strong consistency requires coordination across replicas on every read or write, which adds latency and reduces availability, especially across regions. Monotonic reads gives users a coherent forward-moving experience at a fraction of that cost, which is why globally distributed systems prefer it for most read paths.
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.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
Replication
Keeping copies of the same data on multiple servers. Improves read performance and provides fault tolerance if one server goes down.
Strong Consistency
A guarantee that after a write completes, all subsequent reads will return the updated value. Safer but slower than eventual consistency.
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.
This page explains the idea. The "Monotonic Reads" 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 Monotonic Reads lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Monotonic Reads 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.
