Consistency Models: The Spectrum Between Always Right and Eventually Right
Foundations Series
| # | Post | What it covers |
|---|---|---|
| 00 | Intro | What the Foundations pillar covers and why it matters |
| 01 | Availability | Uptime, the nines, and why 99% isn't good enough |
| 02 | Reliability | Correctness over time — when uptime isn't enough |
| 03 | Latency vs Throughput vs Bandwidth | The three numbers that define system performance |
| 04 | ACID vs BASE | Two philosophies for handling data under pressure |
| 05 | CAP Theorem | The impossibility result every distributed system runs into |
| 06 | PACELC Theorem | What CAP doesn't tell you about latency |
| 07 | Consistency Models ← you are here | The spectrum from "always correct" to "eventually correct" |
| 08 | Single Point of Failure | Why one weak link breaks the whole chain |
| 09 | High Availability vs Fault Tolerance | Similar goals, very different strategies |
| 10 | Wrap-up | How all nine concepts connect |
Consistency Models: The Spectrum Between Always Right and Eventually Right
The problem
Your team is debugging a subtle but painful bug. A user updates their shipping address. They're immediately redirected to a confirmation page that fetches their profile — and the old address is shown. They update it again. Same result. They call support, furious, convinced the system isn't saving their changes.
It is saving them. Just not where that particular read is going.
You have three database replicas. Writes go to the primary. Reads are load-balanced across all three. The replication lag between primary and replicas is roughly 200ms. So for the 200ms window after a write, two out of three reads will return the old address.
Your database is "eventually consistent." But you never stopped to ask: what exactly does that mean for this specific read? What does your system actually promise a user about what they'll see after a write?
That question — what does your system promise? — is what consistency models are for.
The core idea
A consistency model is a contract between a distributed system and the applications that use it. It defines precisely what a client can expect to observe when reading data that may have been written by itself or another client, possibly on a different node.
Consistency is not binary. It is a spectrum. At one end: every read everywhere reflects the latest write everywhere. At the other: reads might return any historical value and there's no guarantee of when they'll catch up. Between those two extremes lies a rich set of models — each offering different guarantees, at different performance costs, suitable for different use cases.
The reason this matters: you cannot build correct application logic on top of a consistency model you don't understand. If you assume your reads are always current and they aren't, you get bugs like the shipping address problem above. If you demand stronger consistency than you actually need, you pay a latency and throughput tax that compounds at scale.
The analogy: a team editing a shared document
Imagine a team spread across Sydney, London, and New York, all editing the same project document — but with different collaboration tools:
Google Docs — everyone sees every keystroke in real time. The moment someone in London types a sentence, Sydney and New York see it appear. This is strong consistency.
A shared cloud file (Dropbox/OneDrive) — changes sync within seconds but not instantly. For a brief window, different team members might have different versions open. If two people edit the same paragraph simultaneously, there's a conflict to resolve. This is closer to eventual consistency with conflict resolution.
Email attachments — someone sends a v1, another person edits v1 and sends v2, a third person edits v1 separately and sends v3. There is no single agreed version until someone manually merges. This is eventual consistency with significant divergence windows and manual reconciliation.
The document is the same in all three cases. The consistency model — the contract about who sees what and when — is completely different.
The spectrum of consistency models
From strongest to weakest:
Linearisability (Strict Consistency)
The strongest guarantee. Every read returns the value of the most recent write, as if there is exactly one copy of the data and operations happen atomically one at a time in real time. If a write completes at time T, any read at time T+1 anywhere in the system will see it.
What it costs: every read must coordinate with every write — typically through a single leader or a consensus protocol. Latency scales with the slowest participating node. Geographic distribution makes this extremely expensive.
Where it appears: Zookeeper, etcd, Google Spanner (approximately). Used for distributed locks, leader election, configuration management — anywhere that requires a single authoritative truth.
The guarantee in plain terms: if you update your password and immediately log in from a different device, you can use the new password.
Sequential Consistency
Slightly weaker than linearisability. All operations appear to execute in some sequential order, and that order is the same from every client's perspective — but it doesn't have to match real-world time. If two operations happen close together, sequential consistency allows the system to order them arbitrarily, as long as all clients see the same order.
What it costs: still requires coordination, but less strictly tied to wall-clock time. Somewhat more practical than linearisability for distributed systems.
The guarantee in plain terms: everyone agrees on the order events happened — but that order might not perfectly match the clock on the wall.
Causal Consistency
Operations that are causally related — where one operation could have influenced another — are seen in the correct order by all clients. Operations with no causal relationship can be seen in any order.
This is the model that matches how humans intuitively think about communication. If Alice posts a message and Bob replies to it, everyone should see Alice's post before Bob's reply. But two unrelated posts by Alice and Carol have no causal link, so different clients can see them in different orders.
What it costs: the system must track causal dependencies — typically using vector clocks or similar mechanisms. More overhead than eventual consistency, significantly less than linearisability.
Where it appears: MongoDB's causal consistency sessions, some configurations of Cosmos DB. Common in collaborative applications.
The guarantee in plain terms: if you can see a reply, you can see the message it's replying to. Causes always precede effects.
Read Your Own Writes (RYOW)
A client always sees its own writes — even if other clients might not yet. After you write a value, any subsequent read by you will return that value or something more recent. Other clients might still see an older version.
This is the minimum consistency guarantee required to prevent the shipping address bug from the opening scenario. It's also one of the most practically important guarantees for user-facing applications, because users always notice when their own changes don't persist.
What it costs: the system must route a client's reads to a node that has processed that client's writes, or use versioned reads. Session affinity is a common implementation — pinning a user's requests to a specific replica for the duration of their session.
The guarantee in plain terms: your changes are visible to you immediately. Other users might see your changes slightly later.
Monotonic Reads
Once a client has seen a value, it will never see an older value for the same key in subsequent reads. Reads only move forward — you might see stale data, but you won't see data that goes backwards.
Without monotonic reads, a client load-balanced across replicas with different replication lags could read a current value from one replica, then read a stale value from another replica on the next request — appearing to the application as if data was deleted and restored.
What it costs: the system must track per-client read progress and ensure reads are served from nodes at least as up-to-date as the client's last seen version.
The guarantee in plain terms: time only moves forward. You might read a slightly old value, but you'll never read something older than what you already read.
Monotonic Writes
A client's writes are applied in the order they were issued. If you write value A then value B, no client will ever see B without also seeing A applied first.
What it costs: minimal — mostly write ordering guarantees within a single client session.
The guarantee in plain terms: your writes happen in the order you made them. You won't see your second write applied before your first.
Eventual Consistency
The weakest meaningful guarantee. Given enough time with no new updates, all replicas will converge to the same value. There is no bound on how long convergence takes. There is no guarantee about what you'll read in the meantime — you might read any historical version.
Eventual consistency is not "anything goes." It promises convergence. It just doesn't promise when, and it makes no guarantees about intermediate reads.
What it costs: nothing, essentially — this is the natural state of an unreplicated distributed system. It's what you get without any additional consistency mechanism.
Where it appears: DNS propagation, social media feeds, shopping cart recommendations, any system where brief staleness is tolerable and scale is the primary concern.
The guarantee in plain terms: everyone will eventually agree. Right now, they might not.
The models in context
Strongest ──────────────────────────────────────── Weakest
Linearisability → Sequential → Causal → RYOW → Monotonic → Eventual
│ │ │ │ │ │
Any node, Global Cause Your No time Just
any time order before writes travel converges
agreed effect visible eventually
Most real systems don't pick one model for everything. They layer them:
The primary database enforces linearisability for writes
Read replicas offer eventual consistency with monotonic reads
User-facing sessions use RYOW for their own data
Background analytics accepts pure eventual consistency
Choosing the right model
| Use case | Minimum model needed | Why |
|---|---|---|
| Distributed locks, leader election | Linearisability | Must have one authoritative truth |
| Financial transactions | Linearisability or sequential | No double-spends, no lost writes |
| User profile reads after update | Read Your Own Writes | Users must see their own changes |
| Social media feed | Eventual | 500ms staleness is imperceptible |
| Collaborative editing | Causal | Replies must follow their messages |
| Read-heavy analytics | Eventual | Slightly stale counts are acceptable |
| Multi-device session | Monotonic reads | No time-travel between devices |
The practical rule: use the weakest model that still gives your application correct behaviour. Every step stronger costs latency and throughput. Use that cost only when your use case genuinely requires it.
The tradeoffs
Stronger consistency = higher latency, lower throughput. Linearisability requires coordination on every operation. In a geographically distributed system, that coordination takes time proportional to the distance between nodes. There is no way around this — the speed of light is a hard limit.
Weaker consistency = more application complexity. Eventual consistency pushes conflict resolution logic into the application layer. You need to decide: what happens when two clients update the same record simultaneously? Last-write-wins loses data silently. Operational transforms (used in collaborative editors) preserve all changes but are complex to implement. Custom merge logic is powerful but requires deep domain knowledge.
Session guarantees are often the pragmatic middle ground. RYOW and monotonic reads give users a consistent experience of their own actions without requiring global coordination. Many user-facing applications only need session-level guarantees — not global linearisability — and can achieve excellent user experience at a fraction of the coordination cost.
The one thing to remember
"Eventually consistent" is not a consistency model — it's the bottom of a spectrum. Before accepting a database's default consistency setting, ask what your application actually needs: does a user need to see their own writes immediately? Does a reply need to appear after its message? Does a balance update need to be globally visible before the next read? Name the model you need, verify your database provides it, and test the edge cases before production finds them for you.
← Previous: PACELC Theorem — the latency vs consistency tradeoff on every operation
→ Next: Single Point of Failure — now that we understand what distributed systems promise about data correctness, we turn to what happens when the components delivering those promises fail.
