Imagine you and your friend both open the same Google Doc at the same time. You type something. Does your friend see it instantly? After a delay? Ever?
That question — when does everyone see the same thing? — is what consistency is all about. And it turns out, there’s no single right answer. Different apps make different choices depending on what matters more to them: speed, correctness, or availability.
Let’s walk through each type using everyday examples.
Table of Contents
Linearizability
What you see is what it is, right now
The everyday version: You withdraw ₹500 from an ATM. Your checks your account balance on your phone at the same second. You see ₹500 less. Instantly. No lag, no confusion.
Why it matters: Banking, flight seat booking, hospital records — anywhere two people acting on stale data causes real-world harm. You cannot let two people book the same last seat on a flight.
The catch: The system has to pause and check with all its servers before answering. That takes time. If a server is unreachable, it may refuse to answer at all rather than risk giving you wrong information.
Used in: ATMs, distributed locks, Kubernetes leader election (etcd), Google Spanner.
Sequential Consistency
Everyone agrees on the story, even if the timing is fuzzy
The everyday version: Three friends watch the same cricket match recording, but at different times. They all watch every ball in the same order. Nobody sees ball 47 before ball 23. The order is preserved, even though they’re not watching live.
Why it matters: The order of events matters, but the exact real-time timestamp doesn’t. As long as everyone agrees on what happened first, second, and third, the system is correct.
The catch: Slightly weaker than linearizability. Two events that happened simultaneously in real life might be ordered differently by different nodes — but they’ll all pick the same ordering.
Used in: Multi-core processor memory models, some database replication setups.
Causal Consistency
If one thing caused another, everyone sees them in order
The everyday version: You post a question on WhatsApp: “Anyone free tonight?” Your friend replies, “Yes!” A third person opens the chat. They must see your question before they see the reply. It would make no sense to show the reply without the original message.
But two totally unrelated messages — your question and a different friend’s meme posted at the same time — can appear in any order. They have nothing to do with each other.
Why it matters: Messaging apps, comment sections, collaborative editing. The relationships between events matter, not perfect global ordering.
The catch: The system needs to track which events are related to which. That’s extra bookkeeping, but much cheaper than full linearizability.
Used in: WhatsApp-style messaging, Google Docs (under the hood), and MongoDB causal sessions.
Read-Your-Writes
You always see your own changes
The everyday version: You update your Instagram bio. You hit save. You refresh the page. You see the new bio. Obviously — right?
Actually, if Instagram has 50 servers around the world, your update might only reach one server initially. Without this guarantee, you might refresh and hit a different server that hasn’t received your update yet, showing you the old bio. Embarrassing and confusing.
Read-your-writes says: you will always see your own changes. Other people around the world might see the old bio for a few seconds — that’s okay.
Why it matters: Any app where users edit their own data and expect to see the result. Shopping cart updates, profile changes, and settings.
The catch: It only protects your own session. Your friend might still see the old bio briefly. This is a personal guarantee, not a global one.
Used in: Almost every user-facing web app — Amazon cart, Instagram profile, Gmail settings.
Eventual Consistency
It’ll get there… eventually
The everyday version: You tweet something. Your follower in Mumbai sees it in 0.1 seconds. Your follower in New York sees it 2 seconds later. Your follower in Tokyo sees it 5 seconds later. Everyone sees it eventually — just not at the same instant.
Meanwhile, the like counter on your tweet might show 143 likes on one server, and 147 likes on another server for a brief moment. Nobody panics. Within seconds, both servers agree.
Why it matters: For things like like counts, view counts, DNS records, and CDN caches — being slightly stale for a second is totally fine. In exchange, the system is blazing fast and always available. Even if half the servers go down, you still get an answer.
The catch: During the lag period, different users might see different things. If correctness in that window matters (like a bank balance), this model is not safe.
Used in: Twitter/X likes, YouTube view counts, Amazon S3, Cassandra, DNS (when you change your domain’s IP, it takes time to propagate everywhere).
The Simple Trade-Off
| Model | Correctness | Speed | Real example |
|---|---|---|---|
| Linearizability | Highest | Slowest | ATM withdrawal |
| Sequential | Very high | Slow | CPU memory |
| Causal | Good | Medium | WhatsApp threads |
| Read-your-writes | Partial | Fast | Instagram bio |
| Eventual | Weakest | Fastest | YouTube likes |
Short
- Linearizability — looks like a single machine; every op is instantly visible to all.
- Sequential — all nodes agree on one order, but it needn’t match wall-clock time.
- Causal — if A caused B, everyone sees A before B; unrelated ops can diverge.
- Read-your-writes — you always see your own writes; others may still lag.
- Eventual — replicas will converge once writes stop; no guarantees mid-flight.
The Golden Rule
No model is universally better. The question is always: what breaks if two users see different things for a few seconds?
If the answer is “someone gets double-charged” or “two pilots get cleared to land on the same runway” — use strong consistency.
If the answer is “one person sees 1.2 million views, and another sees 1.3 million for half a second” — eventual consistency is fine, and you get much better performance for free.
Great engineers don’t pick the strongest model by default. They pick the weakest model that doesn’t break their application.
