Monotonic Reads
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.
What is Monotonic Reads?
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.
What monotonic reads actually guarantees
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.
How it works under the hood
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. DynamoDB and Cosmos DB use token-based mechanisms like this so a client can move between replicas and still keep its reads monotonic.
When to use it and the trade-offs
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.
A concrete example
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.
Where it is used in production
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.
Frequently asked questions
- What is the difference between monotonic reads and read-your-writes consistency?
- 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.
- Is monotonic reads the same as strong consistency?
- 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.
- Does monotonic reads apply across different users?
- 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.
- How do databases actually enforce it?
- 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.
- Why not just always use strong consistency and avoid the problem?
- 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.
Learn Monotonic Reads 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.
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.