Lesson 2.3 · 15 min
Consistency models
Route reads across a lagging leader and followers, watch users miss their own edits or go back in time, then fix it one guarantee at a time.
The idea in plain words
When the same data lives on several machines, a copy may briefly lag behind. A consistency model is the rule for how out of date a read is allowed to be: always fresh, fresh for your own changes, or “it will catch up soon”.
The problem it solves
When data lives on several machines, a write reaches them at slightly different times. A user reading from a copy that hasn’t caught up yet sees old data, and sometimes that looks like a bug.
How it works
- A write goes to one copy first (often a primary) and then spreads to the others.
- For a short time, different copies return different values.
- A consistency model is the promise about what a read may return during that time.
- Strong models always return the latest write, but every read must check with others, which is slower.
- Weaker models return whatever is nearby, which is fast but can be stale. Many apps mix models per feature.
Example
You change your profile name and refresh. If the refresh hits a copy that is 2 seconds behind, your old name appears and you think the save failed. “Read your writes” fixes exactly this by sending your reads to a copy that has your change, while other users may still see the old name for a moment.
Key terms
- Strong (linearizable)
- Every read returns the most recent write, as if there were one copy.
- Eventual consistency
- Copies may disagree for a while but end up the same once writes stop.
- Read-your-writes
- You always see your own changes, even if others see them later.
- Replication lag
- How far behind the primary a copy is, in time or in writes.
- Anomaly
- Something odd a user sees because of lag, such as a comment that disappears on refresh.
In this lesson you'll learn
- The five common promises, from linearizable down to eventual, and the anomaly each one prevents.
- How read routing (pinning, catch-up checks, leader reads) creates each guarantee.
- How to pick the weakest model that users won't notice, per feature.
Sections
- Theory: the ladder
- Theory: replica lag
- Theory: cause before effect
- Design: pick a model
- Check yourself
Cheat sheet
| Linearizable | latest write, real time, everyone |
|---|---|
| Causal | cause shown before effect |
| Read-your-writes | you see your own edits |
| Monotonic reads | never back in time |
| Eventual | converges once writes stop |
The interactive simulations and the quiz load with JavaScript.