The Consistency Spectrum

You edit a post. You hit save. The page confirms it. Two seconds later you refresh — and your edit is gone.

You refresh again, and it's back.

Nothing crashed. Nothing was deleted. No other human touched your post. And I can show you the exact moment it happens, because I built it on a real Postgres with two replicas and caught it:

That is not a bug in the database. Every machine in that system is behaving perfectly, doing precisely what it was designed to do. What you're looking at is a consistency anomaly — and it has a name, and there's a specific, cheap guarantee that forbids it.

Now the confession.

Way back in Consistency: First Taste of the Hardest Trade-off, you were told there are two answers: strong consistency, where writes wait until every copy agrees, and eventual consistency, where they don't. That was a good, honest simplification — and it was a simplification. There aren't two answers. There's a ladder, with a lot of rungs between those two, and each one has a name, a precise meaning, and a price.

And in Quorums: N, R, W I admitted I'd been cheating. We've now said "stale," "latest," and "strong consistency" a dozen times each without ever defining any of them. Time to stop.

Here's the idea that makes this whole topic collapse from memorisation into understanding, and it's the only thing I'd ask you to take away if you read nothing else:

A consistency model is nothing more than a list of the weird things it promises will not happen to you.

That's it. Stronger model = shorter list of allowed weirdness = more coordination = more money. So we're going to learn the weird things first — they're concrete, they're what your users actually experience, and they're what wakes you up at 3am — and then the models will just be names for the thing that forbids them.

In this lesson: the anomalies, one by one, each captured on a real database; the ladder from eventual up to linearizable and what each rung buys; why "eventual consistency" is a far weaker promise than it sounds; the two things that will separate you from most engineers in an interview (the word "consistency" means three completely unrelated things, and linearizable is not the same as serializable); and the practical punchline — the bugs your users actually report are the cheap ones to fix.

Scope: what happens to all of this when the network splits in half — when you must choose between staying consistent and staying up — is CAP, Properly, and it's next. Here we're just learning the vocabulary, on a healthy network.

Forget the models. Here is what actually goes wrong when your data lives on more than one machine. Every one of these is something a real user has filed a real support ticket about.

I ran all of them on a live Postgres: one leader, two streaming replicas, with replica B deliberately lagging behind (0 bytes behind on A, 240 bytes behind on B — a completely ordinary Tuesday).

Anomaly 1: "I saved it, and my own edit vanished."

You write to the leader. Your very next page load gets load-balanced onto a replica that hasn't caught up yet. You are now looking at your own post, without your own edit.

This is the most infuriating one, because the user knows they did it. They will refresh. They will save again. They will email you. The guarantee that forbids it is called read-your-writes, and it says exactly what it sounds like: you always see your own writes. Note how narrow that promise is — it says nothing about seeing anybody else's writes. It's a promise about your own session, and that narrowness is what makes it cheap.

Anomaly 2: "I refreshed twice and it went backwards."

This is the one from the top of the lesson, and it's the strangest thing a distributed system can do to a person. Two reads. No writes in between. Different answers — and the second one is older.

The guarantee that forbids this is monotonic reads: once you have seen a value, you will never subsequently see an older one. Time may stand still. It may not reverse.

And here's a subtlety worth pausing on, because it surprises people: monotonic reads does not mean your reads are fresh. It only means they never go backwards. I fixed this anomaly by pinning the user to a single replica — the stale one — and reading three times:

Stale-but-stable is a real guarantee, and it's often exactly the one you want. A user who is consistently a few seconds behind will never notice. A user who is bouncing between fresh and stale will think your site is broken.

Anomaly 3: "The reply showed up before the post."

Alice posts "I lost my keys." Bob reads it and replies "Check the car!" Both writes propagate independently across the cluster — and Bob's reply happens to arrive at some replica before Alice's original does. Carol loads the page and sees a reply to nothing. A conversation with the cause missing and the effect present.

The guarantee is writes-follow-reads (and its bigger sibling, causal consistency): if you read something and then write in response to it, anyone who sees your response must also see the thing you were responding to. Effects never outrun their causes.

Anomaly 4: "Someone else's finished write wasn't visible to me."

Alice's write completes. The database returns success. Bob reads a microsecond later — and gets the old value. Nothing here is Alice's session, or Bob's session; this is about real time and about everybody. Forbidding this one is the strongest thing you can ask for, and it has the grandest name: linearizability.

Four anomalies. Four guarantees. Now watch how the whole spectrum is just these, stacked.

Bottom rung, and let's be blunt about it.

Eventual consistency forbids... almost nothing. Here is the actual promise, stated precisely: if you stop writing, the replicas will eventually agree.

Read that twice. It doesn't say when. It puts no bound on "eventually" — a second, an hour, whatever. And it says nothing at all about what you're shown in the meantime; any intermediate value is permitted. It's a promise about the end of the world, not about Tuesday. Formally it's a liveness guarantee with no safety guarantee whatsoever, and Kleppmann is characteristically blunt about it: it is a very weak guarantee. Every single one of the four anomalies above is allowed under eventual consistency, and none of them counts as a violation.

Which is precisely why the next rung exists.

The session guarantees. Four of them, and they came out of the Bayou project at Xerox PARC, designed for mobile users who were only intermittently connected. Their stated goal is the best one-sentence summary of practical consistency ever written: to present each application with a view of the database that is consistent with its own actions, even when it's reading and writing across servers that don't agree with each other.

• Read-your-writes — you see your own writes.
• Monotonic reads — you never go backwards.
• Monotonic writes — your writes are applied in the order you made them.
• Writes-follow-reads — your reply never outruns the thing it replies to.

Notice what they all have in common: they're promises to you, about your session. They don't attempt to make the whole cluster agree about anything. That's why they're cheap — and, as we'll see, that's why they're the ones that matter most.

Causal consistency. Now we step beyond a single session. Everyone, everywhere, sees causally-related operations in the right order. If B was caused by A, nobody sees B without A. Operations that are genuinely concurrent — unrelated, neither caused the other — may still be seen in different orders by different people, and that's fine, because nobody can tell.

Sequential consistency. Everyone agrees on one single order of all operations, and each process's own operations keep their program order. But — and this is the subtle part — that agreed order need not match real time. The whole system can be running a few seconds behind reality, as long as everybody is behind in the same way.

Linearizability. The top of our ladder, and the strongest. Herlihy and Wing, 1990: every operation appears to take effect instantaneously at a single point in time, somewhere between when you called it and when it returned — and that ordering respects real time.

The intuition is simpler than the definition: linearizability is the illusion that there is only one copy of your data. All that replication, all those machines — the system behaves exactly as though there's a single database that everyone talks to, one operation at a time. The moment a write completes, everyone sees it. No exceptions, no windows, no "eventually."

That illusion is expensive, and now we should talk about the bill.

Every rung you climb, somebody has to coordinate. And coordination is not free — it's a round trip, and round trips are the speed of light plus a switch.

To keep the illusion of a single copy, a linearizable system has to make sure that no read anywhere can return a value older than the newest completed write anywhere. There's only one way to do that: the machines must talk to each other before answering you. So every operation is paying for a conversation.

Here is the thing nobody tells you, though, and it's worth being precise about. The bill is not a property of the algorithm. It's a property of the map.

Let's price it honestly. A read that a nearby replica can answer out of its own copy is just a read — I measured it on the Postgres I've been using all lesson, and a primary-key SELECT came back in a median of 0.46 ms. Call it half a millisecond. Every rung below the top is served that way, so every rung below the top costs the same half-millisecond. Read-your-writes, monotonic reads, causal — they are routing rules, and routing is free.

Linearizability is the one rung that must ask the leader before it dares answer you. That's one extra round trip, and a round trip costs whatever the distance costs:

Read that table again, because it is the whole economics of this lesson in six lines. Put your replicas in one rack and linearizability is nearly free — 0.55 ms against 0.5 ms, a rounding error. Nobody agonises over strong consistency inside a single datacentre, and now you know why: there's nothing to agonise about. Put those same replicas on opposite sides of an ocean and the identical algorithm now costs 70.5 ms a read — about 140× a local one — while every weaker rung carries on answering in half a millisecond, completely unmoved.

The algorithm never changed. The distance did. So when somebody says "strong consistency is expensive," the honest reply is: expensive where? It's a question about your map, not your database.

And then there's the sharp end. From DDIA, and this is the part that matters:

If your application requires linearizability, and some replicas are disconnected from the others by a network problem, those replicas cannot process requests at all. They must wait for the network to come back, or return an error. Either way, they become unavailable.

Sit with that. A linearizable system, faced with a network problem, will refuse to serve you — not because it's broken, but because answering you might mean lying to you, and it promised not to. It's the Cannot achieve consistency level QUORUM error from the last lesson, promoted to a philosophy.

You have now walked directly into the most famous result in distributed systems, and I'm going to stop right at its edge, because it deserves a lesson of its own — that's CAP, Properly, and it's next. For now, just hold the shape of it: strength costs latency always, and availability when the network misbehaves. The ladder isn't a quality ranking where higher is better. It's a price list.

Anomalies are much easier to understand when you cause them yourself.

Below is a system with a leader and two replicas, one of which lags. Pick a consistency model, then drive a real scenario: post something, edit it, refresh, reply. The widget shows you which replica each read landed on and what it returned — and whether what just happened was an anomaly or something the model you chose has forbidden.

Try this first. Stay on eventual and edit your own post, then refresh twice. The second read lands on the lagging replica and your own edit is gone — that's read-your-writes, violated, live.

Now reset and change exactly one thing: let Bob edit the post instead of you. Refresh twice again. Same lag, same replicas, same two clicks — but now the version you're shown goes v2 → v1. It runs backwards. That's monotonic reads, violated, and it's a different bug: it isn't about losing your write, it's about time reversing on a write that was never yours. Then have Bob reply, and watch the reply reach you before the edit it's replying to — causal, violated.

Then climb. Each rung you step onto switches off exactly one more of those, and the identical clicks stop working.

And then do the thing that actually settles the cost argument: move your replicas. The widget lets you put them in the same rack, across a country, or across an ocean. Watch what happens to the price tags — only one of the five moves. Eventual, read-your-writes, monotonic reads and causal all sit at half a millisecond no matter where you drag your machines, because a nearby replica answers them. Linearizable goes from 0.55 ms to 9.5 ms to 70.5 ms, because it — and only it — has to ask the leader, and the leader just moved to Virginia.

Here's the thing that trips up engineers who are otherwise very good, and getting it right will genuinely mark you out in an interview.

The word consistency is used, in our field, for three entirely unrelated concepts. They are not variations on a theme. They are homonyms — like bank the riverside and bank the building.

1. The C in ACID. This means your invariants hold. If your rule is "the two account balances must always sum to £100," then a consistent transaction is one that doesn't break that rule. It is a property of your application's logic. It has nothing whatsoever to do with replication, or with distributed systems, or with anything in this lesson. Honestly, the C was arguably put in ACID to make the acronym pronounceable.

2. The C in CAP. This means linearizability — and it isn't a loose analogy, it's literal: linearizability is the "C" in Gilbert and Lynch's formal proof of the CAP theorem. It's a real-time recency guarantee about single operations on single objects.

3. The C in "eventual consistency." This means convergence — the replicas will agree, someday, if you leave them alone.

Invariants. Recency. Convergence. Three different words wearing the same coat. When someone says "we need consistency here," the useful next question is not "how much?" — it's "which one?"

And the second trap, which is the same disease in a more specific form.

Serializability you already know — we taught it in MVCC: Readers Don't Block Writers and it's the I (isolation) in ACID. It's a guarantee about transactions: groups of operations, over many objects, and the promise is that the result is equivalent to running them one after another in some serial order. Note that word: some. Serializability doesn't care which order, and it imposes no real-time constraint at all. A serializable database is perfectly entitled to behave as though your transaction happened ten minutes ago, as long as some consistent story exists.

Linearizability is about single operations on a single object, and it cares about real time and nothing else: the moment a write finishes, everyone sees it.

They are not stronger and weaker versions of each other. They're orthogonal. One is about grouping (transactions), the other is about timing (recency). You can have either without the other. Have both and you get the thing with the fabulous name: strict serializability.

Why is this so confusing? Because the two words come from two different tribes. Linearizability grew up in the distributed-systems and concurrent-programming community. Serializability grew up in the database community. They were solving different problems, they never coordinated their vocabulary, and now we all live with it.

The one-line version, worth memorising exactly: serializability is about transactions being equivalent to some serial order; linearizability is about that order matching real time.

Now the part that turns all this vocabulary into an engineering decision, and it's genuinely good news.

Go back and look at the anomalies that actually generate support tickets:

• "I saved it and it didn't save." — read-your-writes
• "It keeps flickering between old and new." — monotonic reads
• "The replies are out of order." — writes-follow-reads

Every single one of those is a session guarantee. Not one of them requires linearizability. Not one of them requires the entire cluster to agree about anything.

And session guarantees are cheap, because they're promises about one user's own experience — which means you can keep them locally, without a global conversation. Here are the two fixes, and I ran both of them on the real cluster:

Read-your-writes: after a user writes, route that user's reads to the leader for a few seconds (or until you know their write has propagated). Everyone else carries on hitting replicas as normal.

Monotonic reads: give each user a sticky session — always route them to the same replica. Even if that replica is behind, they will never see time reverse, because they're only ever looking at one clock.

That's it. A routing rule and a sticky cookie. You just bought most of the felt correctness of a linearizable system for approximately none of the price — no consensus, no coordination round trips, no unavailability when the network hiccups.

This is the move, and it's what separates someone who has memorised the ladder from someone who can use it: don't ask "how strong should my database be?" Ask "which anomaly is actually hurting my user, and what's the cheapest rung that forbids it?" Nine times out of ten the answer is a session guarantee, and the tenth time — money, inventory, uniqueness — is when you go and pay for the real thing.

Default to eventual, and then fix the anomalies your users can actually see. Most data — feeds, profiles, comments, view counts, search results — genuinely does not need coordination. Serve it from replicas and go home.

Add session guarantees wherever a human is watching. If a user can perform an action and then look at the result of it, you want read-your-writes. If they can refresh, you want monotonic reads. These are cheap, they are local, and they are the difference between "this site feels solid" and "this site feels haunted."

Reach for causal when order is meaning. Threaded conversations, comment replies, edit histories, collaborative documents. If an effect can outrun its cause, your product will look insane.

Pay for linearizability only where being wrong is unacceptable. Account balances, inventory decrements on the last item, unique username registration, locks, leader election. And when you buy it, buy it narrowly — for that one table, that one operation — not across your entire system, because you'll be paying the coordination tax on every unrelated request forever.

And say which "consistency" you mean. When somebody in a design review says "this needs to be consistent," the sentence has three possible meanings and they haven't told you which. Ask.

You can make a real database run time backwards in about five minutes, and once you've watched it happen you'll never confuse these models again. Everything below is what I actually ran.

Stand up a primary and two streaming replicas (the recipe is in Replication Topologies — a pg_basebackup -R for each). Then deliberately make one of them lag:

Experiment 1 — lose your own write. Read from replica B. Predict it first: you are looking at your own post, one second after saving it. What do you see?

Experiment 2 — make time run backwards. This is the one. Read from replica A (which is caught up), and then from replica B (which isn't). No write in between — you are simply refreshing a page and getting load-balanced differently:

Experiment 3 — fix it with a sticky session, and notice what the fix actually gives you. Read from replica B three times in a row. It's stale — it's still showing the un-edited post — but it never goes backwards.

That's the moment the penny drops: monotonic reads doesn't make your data fresh. It makes your data stable. And stable-but-slightly-behind is invisible to users, while flickering is unbearable.

Finally, SELECT pg_wal_replay_resume(); and watch all three converge. That convergence — and nothing more than that — is the entire promise of eventual consistency.

• "Eventual consistency means it'll be correct in a moment." It means: if you stop writing, the replicas will eventually agree. No bound on "eventually," and no promise whatsoever about what you see before then — any intermediate value is permitted. It's a liveness guarantee with no safety guarantee. As a contract with your users it is nearly vacuous, and that's why the session guarantees exist.
• "Strong consistency is the C in ACID." No. The C in ACID is your invariants hold — an application-logic property with nothing to do with replication. The C in CAP is linearizability. The C in eventual consistency is convergence. Three unrelated ideas, one overloaded word.
• "Linearizable and serializable are basically the same." They're orthogonal. Serializability = transactions equivalent to some serial order (no real-time constraint). Linearizability = single operations, ordered by real time. Both together = strict serializability.
• "Monotonic reads means my reads are fresh." No — it means they never go backwards. I achieved monotonic reads by pinning a user to the stale replica. Stale-but-stable is the guarantee, and it's usually the one you actually want.
• "Stronger is always better." Stronger means more coordination: more latency on every operation, and — when the network misbehaves — refusing to answer at all. It's a price list, not a quality ranking.
• "I need linearizability because users complained about stale data." Almost certainly not. Go and read the complaints: "it didn't save," "it keeps flickering," "replies are out of order" — those are session guarantee violations, and a sticky session plus read-from-leader fixes them for free.
• "Eventual consistency means the database is unreliable." It means the database made a different trade than you assumed. Your job is to know which anomalies it lets through, and forbid the ones that matter to your users.

• A consistency model is just a list of anomalies it forbids. Learn the anomalies — they're what users actually experience — and the models become names, not memorisation.
• The four anomalies, all captured live: your own edit vanishes (read-your-writes); you refresh twice and time runs backwards (monotonic reads); a reply outruns its post (writes-follow-reads / causal); someone's completed write isn't visible yet (linearizability).
• The ladder: eventual → the four session guarantees → causal → sequential → linearizable. Each rung forbids more and costs more.
• "Eventual consistency" promises far less than it sounds: if writes stop, replicas will eventually agree. No time bound, and no promise at all about what you see in the meantime.
• Linearizability is the illusion of a single copy — every operation appears to happen instantaneously, in real-time order. It's the strongest, and it costs a coordination round trip on every operation and your availability when the network breaks.
• "Consistency" means three unrelated things: invariants (the C in ACID), recency (the C in CAP = linearizability), convergence (the C in eventual consistency). Ask which one people mean.
• Linearizable ≠ serializable. Serializable = transactions equivalent to some serial order. Linearizable = single operations in real-time order. Orthogonal. Both = strict serializable.
• The punchline: the bugs users report are the cheap ones. Read-your-writes and monotonic reads are fixed with a routing rule and a sticky session — most of the felt correctness of a linearizable system, for almost none of the price. Don't ask "how strong should this be?" Ask "which anomaly is hurting my user, and what's the cheapest rung that forbids it?"

Next — CAP, Properly: we've been assuming the network works. It doesn't. And when it splits in half, that ladder you just learned stops being a menu and becomes an ultimatum: you can keep your consistency, or you can keep serving requests. Not both. The theorem everyone quotes and almost nobody states correctly.