"Eventually consistent" sounds like one thing. It's actually six. Between the rigorous mathematical guarantee of linearizability and the loose promise of eventual, there's a precise spectrum — and your database lives somewhere on it whether you've thought about it or not.
Open any distributed database's marketing page and you'll see one of two phrases: "strongly consistent" or "eventually consistent." Both are useless without qualification. Strongly consistent on every read? Only under load below some threshold? Only on the same replica? Eventually consistent within how long? A millisecond? A minute? "Whenever your network unpartitions"? Every one of these is a real product. Every one ships with the same English-language summary. The conversation can't even begin until you know which precise model is on the table.
region-failover setups.The fix for this fuzziness is the same as every other fuzziness in distributed systems: use the precise names. The consistency-model literature has been precise about this since the 1970s; the field of practice took a while to catch up. By the end of this module, when you see "strongly consistent" in a database's docs, your next instinct will be "which one — linearizable, sequential, or just primary-only-reads?" The answers are very different.
This module climbs the consistency ladder rung by rung — from linearizability at the top (every read sees the latest write, no exceptions) down through sequential, causal, the four session guarantees, and finally to eventual. The lab in §04 lets you take the same scenario of writes and reads and replay it under each model, watching anomalies appear and vanish as you adjust the dial. The point isn't to memorize definitions; it's to feel where each model breaks.
The consistency ladder is well-defined and well-named — the names just don't appear in product brochures, so most engineers haven't met them. Here's the full ladder, top to bottom. Each rung permits everything below it; each rung forbids the anomalies listed in the rungs above it. The higher you climb, the more coordination you need — and the more latency you pay.
Two things to internalize. First, this is a strict hierarchy: linearizable implies sequential implies causal implies read-your-writes (and so on). If your system gives you linearizability, you have all the others for free. If it gives you eventual consistency, you have none of the others — and might be surprised by every anomaly above. Second, the cost grows steeply as you climb. Linearizability requires consensus protocols (M.24 territory); eventual requires nothing but background replication.
The middle rungs — causal and the session guarantees — are where most well-designed systems actually live. They're strong enough to feel correct to users, weak enough to scale. The mistake most teams make isn't picking the wrong rung; it's not knowing they made a pick. Once you can name the level you're on, you can defend or change it on purpose.
Linearizable is the gold standard but expensive. Eventual is cheap but baffling. The middle ground — and the model most user-facing apps actually need — is the family of session guarantees. These promise consistency from a single user's perspective, while still allowing other clients to see different things. They're cheap to implement (often: stick a client's reads to one replica, track its highest-seen version) but eliminate the failures that feel most broken in production. Named in the famous Bayou paper (1994), they're a 30-year-old toolkit barely taught in modern bootcamps.
The anomaly it prevents: "I just posted a comment but it's not on my page when I refresh." Solved by routing the client's reads to the primary (or a replica that has caught up to the client's last write timestamp).
The anomaly it prevents: "I saw 10 likes on this post, refreshed, and now it shows 7." Solved by tagging each client read with the highest version it has seen and requiring future reads to be at least that fresh.
The anomaly it prevents: "I changed my profile name to 'Jane', then to 'J. Doe'. Now it shows 'Jane' again." Solved by tagging writes within a session and serializing them — even across replicas.
The anomaly it prevents: "I read a post, replied to it. Now my reply shows up before the post." Solved by tagging the read's version into subsequent writes from the same session.
These four composed together deliver an experience that feels strongly consistent to any individual user — even though the system is technically still eventually consistent globally. Two users on opposite sides of the world might see different versions of the world for a few seconds, but neither will see their own actions out of order. That property is what makes social media feel coherent at scale: your tweets, your likes, your comments all appear consistent to you, while the global feed converges asynchronously.
This is the cheapest way to make an eventually-consistent system feel correct. No consensus protocol, no synchronous replication, no expensive coordination — just track a few version numbers per session. Most production systems should reach for session guarantees first, and only climb higher (to causal or linearizable) when there's a specific operation that requires it.
Below: four canonical anomaly scenarios. Pick one. Then toggle through the six consistency models. Operations that violate the chosen model glow red. Same exact sequence of events — the question is which model is strong enough to forbid the anomaly, and which is content to allow it. This is the lab where the spectrum becomes intuition.
Loading...
Now you have the names. The next question is which one to pick for a given problem. The honest answer: most operations don't need linearizability. The honest design move: figure out the smallest set of operations that genuinely require strong guarantees, lift those to the appropriate rung, and leave the rest weakly consistent. Below: the rough mapping.
Two practical points. First, a single application typically uses multiple models. The same product reads its inventory count with eventual consistency (it's fine if it's off by a few seconds) but writes order placement with linearizability (you must not double-sell the last item). Engineers who pick one model for the whole system are usually paying too much somewhere and too little somewhere else. Second, the database picks for you unless you say otherwise. DynamoDB defaults to eventual; you have to explicitly ask for strong. Postgres reads from the primary with linearizable semantics by default; you have to deliberately read from replicas to get the cheaper, weaker version. Know your defaults.
The terms that appear in every distributed database's documentation. Master these and the papers, the docs, the debugging conversations all open up.
Test the consistency-model intuition. Click an answer; explanation drops in instantly.
Perfect. The consistency ladder is yours, and "eventual" no longer means one thing. Next: how distributed systems agree on order in the first place — Lamport clocks and the foundations of "happens-before."
Consistency is a precise vocabulary, not a marketing word. These ideas show up in every system you'll touch.
Linearizable, sequential, causal, RYW, monotonic reads, eventual. Each rung forbids more anomalies and costs more in coordination. Knowing the names is the entire fight.
Most user-facing apps need RYW + monotonic reads, not full linearizability. Cheap to add, eliminates 80% of "this feels broken" anomalies. Reach for them first.
Stronger guarantees only for the operations that truly need them. Money is linearizable; like counts are eventual. Pick per operation, not per system.