We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Consistency Models
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Consistency Models
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You check your bank balance: $500. Refresh. $450. Refresh. $500 again. The value oscillates because requests hit different replicas with different lag.
Monotonic reads guarantee that once you see a value, subsequent reads return that value or something newer. Never older. This is the minimum consistency level that prevents users from thinking the system is broken.
Violating monotonic reads creates the most confusing UX: social feeds that un-like posts, dashboards where metrics go backward, shopping carts that lose items and then recover them on the next refresh.
The implementation comes down to a choice: pin the client to a replica, or carry a version token that any replica can check.
Session-based routing (sticky sessions). Pin a user session to a specific replica using a cookie hash or IP hash. Because one replica never travels backwards in its own timeline, monotonic reads are guaranteed by physics. HAProxy, nginx, AWS ALB, and Envoy all support sticky sessions with one config line.
Version tracking. Each read response carries a version token (a timestamp, a sequence number, or a hybrid logical clock value). The client stores the highest token it has seen. On the next read, it sends that token. The system routes the read to a replica that is at or past that version.
| Approach | Complexity | Failure Mode | Used By |
|---|---|---|---|
| Sticky sessions | Low (one LB config) | Breaks on replica failure; failover sends user to stale replica | HAProxy, nginx, most small deployments |
| Version tokens | Moderate (app-layer protocol) | Graceful failover; any caught-up replica can serve | MongoDB (clusterTime), DynamoDB (lastModified), FoundationDB |
| Read from primary | None | Always monotonic, but primary becomes a bottleneck | Simple apps, low read volume |