What Consistency Actually Means: The Ladder Behind "Eventually Consistent"

Every design post on this blog has a line like “browsing can be eventually consistent” or “the seat row needs to be strongly consistent,” and none of them said what that means. That is fine in a design answer, right up until the interviewer asks “consistent how?” and the candidate discovers that they have been using one word for at least five different guarantees.

This post is the ladder. By the end you will be able to name the consistency model a requirement actually needs, say which anomaly you are accepting when you choose a weaker one, point at the mechanism in your design that enforces it, and state its cost. That is the whole competency, and it is one most candidates fake.

Where This Shows Up

Consistency is rarely the headline question. It is the follow-up that exposes a design:

• “Is that strongly consistent?”
• “A user posts a comment and refreshes. Do they see it?”
• “Can you serve that read from a replica?”
• “What happens when the cache and the database disagree?”
• “What does CAP mean for this design?”
• “Two users book the last seat at the same instant. Walk me through it.”
• “How does this behave across two regions?”

What They Are Really Checking

1. Do you know it is a ladder, not a switch? Strong versus eventual is the answer of someone who has read one blog post. The interviewer wants to hear that there are levels, each with a specific guarantee and a specific cost.
2. Can you map a product requirement to the weakest model that satisfies it? Linearizability everywhere is expensive and usually impossible across regions. Eventual everywhere breaks the product. The skill is choosing per data item.
3. Can you name the anomaly you are accepting? “Eventually consistent” means “here is a specific thing the user might see, and here is why it is acceptable.” Without the anomaly, the choice is not a decision.
4. Do you know where the guarantee is enforced? A consistency model is not a database setting. It is a property of a specific path through your design: which node serves the read, what token the client carries, what the replication mode is.
5. Do you know the cost? Every step up the ladder buys a guarantee with latency, availability under partition, or throughput. Naming the cost is what makes the choice credible.

The Gotchas

Gotcha 1: Three different words spelled the same way. The C in ACID (Atomicity, Consistency, Isolation, Durability) means invariants hold after a transaction. The C in CAP (Consistency, Availability, Partition tolerance) means linearizability. And “consistency model” in replication means what a reader can observe relative to writes. Say which one you mean. Interviewers notice when candidates slide between them.

Gotcha 2: Strong versus eventual as a binary. Between those two are sequential, causal, and the session guarantees, and the session guarantees are the ones users actually notice. Skipping them means you cannot express “the author sees their own comment immediately, everyone else sees it within a second,” which is the most common real requirement.

Gotcha 3: Choosing eventual without naming the anomaly. “We can make that eventually consistent” is not a design decision until you add “so a user might see the old count for a second, which is fine for a like counter.”

Gotcha 4: Assuming a primary with replicas is strongly consistent. Writes to the primary are. Reads from a replica are stale by the replication lag, which can be milliseconds or, during a backlog, minutes. If you draw a read replica and say “strongly consistent,” you have contradicted yourself on the board.

Gotcha 5: Assuming the cache agrees with the database. Cache-aside has a window between the database write and the cache invalidation, and a race where a slow read repopulates the cache with a stale value after the invalidation. Say which anomaly the window permits and whether you care.

Gotcha 6: Confusing consistency with durability or atomicity. “The write is committed” says the write will survive. It says nothing about who can see it and when. Different axis.

Gotcha 7: “Kafka guarantees ordering.” Per partition. Across partitions, no. If ordering matters, the partition key is the design decision.

Gotcha 8: Claiming linearizability across two systems. The database and the search index, or the database and the cache, are two systems. No amount of care makes a read that touches both linearizable. The best you get is “the index lags the database by some bounded time,” and you should say so.

Gotcha 9: Ignoring the cost. Linearizability needs coordination. Coordination means round trips. Across regions, per the numbers post, a round trip is 100 milliseconds. A design that puts a linearizable write on the hot path across regions has a 100-millisecond floor on every write, and you should either accept that out loud or move the leader.

Gotcha 10: Mixing up the two axes. Consistency models (linearizable, causal, eventual) describe single-object visibility across replicas. Isolation levels (serializable, snapshot, read committed) describe multi-object transactions on one copy. They combine: strict serializability is serializable transactions that are also linearizable. Know which axis the interviewer’s question is on. “Two users book the last seat” is isolation. “The user refreshes and their comment is gone” is a consistency model.

How to Answer

Step 1: Say which consistency you mean

Word	Means	Example sentence
ACID consistency	Invariants hold after each transaction	“The balance never goes negative”
CAP consistency	Linearizability: every read sees the latest acknowledged write	“After the seat is booked, no one anywhere sees it as available”
Consistency model	The rules for what a reader on any replica may observe	“Eventual with read-your-writes for the author”

One sentence: “By consistency here I mean the replication model, not ACID invariants.”

Step 2: The ladder

flowchart TB
    SS[Strict serializability<br/>serializable transactions + real-time order] --> L
    L[Linearizable<br/>one copy, real-time; reads see the latest ack'd write] --> S
    S[Sequential<br/>one global order, program order respected, not real-time] --> C
    C[Causal<br/>causally related ops seen in order everywhere; concurrent ops may differ] --> SG
    SG[Session guarantees<br/>read-your-writes, monotonic reads, monotonic writes, writes-follow-reads] --> E
    E[Eventual<br/>replicas converge if writes stop; anything goes in between]
    style L fill:#2d6a4f,color:#fff
    style SG fill:#2d6a4f,color:#fff

The two green rungs are the ones you will use in almost every interview: linearizable for the few keys that matter, and the session guarantees for everything a user can notice.

Model	Guarantee	Anomaly it prevents	Typical cost
Linearizable	Every operation appears to take effect instantaneously at some point between its start and its acknowledgment, in real time	Reading a stale value after someone else’s write was acknowledged	Coordination on every operation: a leader, or a quorum, or consensus. Unavailable on the minority side of a partition
Sequential	All clients see the same order of operations, and each client’s own operations appear in program order, but that order need not match wall-clock time	Clients disagreeing about the order of writes	Cheaper than linearizable; rarely offered by name
Causal	If operation B could have depended on A, everyone sees A before B. Concurrent operations may be seen in different orders	A reply appearing before the post it replies to	Version vectors or causal tokens; no global coordination
Read-your-writes	A client sees its own writes	“I posted and it is gone”	Route the client to the writer, or carry a version token
Monotonic reads	A client never sees time go backward	A comment appears, then disappears on refresh	Stick the client to one replica, or carry the last-seen version
Monotonic writes	A client’s writes are applied in the order issued	Editing a profile twice and the first edit winning	Serialize a session’s writes through one path
Writes-follow-reads	A write that happens after a read is ordered after what was read	Replying to a comment on a replica that never saw the comment	Carry read version into the write
Eventual	If writes stop, all replicas converge to the same state	Nothing during the window	Async replication. Cheapest, most available

Step 3: Turn anomalies into symptoms

Interviewers are more convinced by “the user would see X” than by the model’s name.

Anomaly	What the user sees	Which rung prevents it
Stale read after own write	“I changed my name and it still shows the old one”	Read-your-writes
Non-monotonic read	“The message was there, I refreshed, now it is gone”	Monotonic reads
Causal violation	A reply shows up before the post, or a “deleted” post with live comments	Causal
Stale read after someone else’s write	Two users both see the last seat as available after one booked it	Linearizable on that key
Lost update	Two increments, counter goes up by one	Isolation (atomic increment or compare-and-set), not a replication model
Write skew	Two on-call doctors both go off duty because each checked and saw the other on	Serializable isolation

The last two rows are the isolation axis. Saying “that one is isolation, not replication” earns points.

Step 4: Match each requirement to the weakest model that works

This is the core skill. Go through the system’s data items one at a time.

Data item	Requirement	Weakest model that satisfies it	Why not weaker
Seat availability during booking	No double-selling	Linearizable on the seat row, or a serializable transaction over the booking	Any stale read lets two buyers proceed
Account balance for a debit	Never overdraw	Serializable per account, or an atomic conditional decrement	Two concurrent reads of the same balance
Distributed lock, leader election	Exactly one holder	Linearizable	A stale view means two leaders
User’s own profile after editing	Author sees the edit immediately	Read-your-writes	Author refreshing and seeing the old value is a bug report
Comment thread	Replies never appear before parents	Causal	Order across users matters, real time does not
Social feed	Fresh within seconds	Eventual, plus read-your-writes for the author’s own posts	Nobody can tell a two-second lag from a network delay
Like or view counters	Approximately right	Eventual	Off-by-a-few for a second is invisible
Product catalog, config, feature flags	Converges within seconds to minutes	Eventual	Stale is harmless; availability matters more
Shopping cart across devices	Never lose an item	Eventual with a merge rule (union)	Last-writer-wins would drop items added on another device
Inventory count shown on a listing	Roughly right	Eventual	The decrement at checkout is the linearizable part, not the display

The pattern to say out loud: the display is eventual, the decision is linearizable. Most systems have a handful of linearizable decisions surrounded by eventually consistent views.

Step 5: Point at the mechanism

A model is only real if you can say what enforces it.

To get	Mechanism	Cost
Linearizable reads and writes on a key	Single leader per key, reads served by the leader; or consensus (Raft, Paxos) per shard	Leader is a throughput ceiling; a round trip to the leader; unavailable on the minority side of a partition
Linearizable-ish with replicas	Quorum reads and writes where R + W > N, plus read repair	Close, but not linearizable without extra care; Kleppmann covers the edge cases
Read-your-writes	Route the client to the leader for a short window after a write; or the client carries the version of its last write and the replica waits until it has caught up	Sticky routing, or a version token in the session
Monotonic reads	Pin a session to one replica; or carry the last-seen version	Sticky sessions, and failover must handle the pin
Causal	Version vectors, hybrid logical clocks, or a causal session token issued by the store	Metadata per operation; some stores offer it as a mode
Eventual	Asynchronous replication plus anti-entropy or read repair	Cheapest; the only cost is the anomalies you have already accepted
Convergence without lost data	CRDTs (Conflict-free Replicated Data Types) or an application merge function	Design effort; last-writer-wins is the default and it loses data
Read-your-writes across a cache	Write-through, or invalidate on write and version-check on read	The cache-aside race needs either a version or a short TTL you are willing to tolerate

The interviewer’s question “how do you get read-your-writes if reads go to replicas” has a specific answer: the client carries a version token and the replica blocks or redirects until it has that version. If you can say that, you have demonstrated the whole idea.

Step 6: State the cost, once

Coordination costs latency, availability, and throughput. Say it in the form the design needs:

• Latency. Linearizable operations pay at least one round trip to wherever the leader or quorum is. Same data center, half a millisecond. Cross-region, a hundred milliseconds. That is the floor.
• Availability under partition. CAP, stated correctly: when the network partitions, a linearizable system must refuse operations on the side that cannot reach the leader or quorum. An eventually consistent system keeps serving and reconciles later. You do not get to choose the partition; you choose what happens during it.
• The normal case. PACELC extends CAP: even with no partition, you trade latency for consistency. Most of the time there is no partition, so this is the trade-off you actually live with.
• Throughput. A single leader per key is a ceiling. Shard the keyspace so each shard has its own leader.

Step 7: The sentence to say in an interview

Put it together in one paragraph, per data item, in this shape:

For the seat row I need linearizability, enforced by a single leader per event shard with reads served from the leader during the booking flow. The cost is that booking is unavailable for that shard if the leader is unreachable, which I accept because selling a seat twice is worse than a brief outage. For the seat map that everyone else browses, I want eventual consistency served from replicas and a cache, with a two-second staleness bound. The anomaly is that a user may briefly see a seat as available that was just taken, and the booking flow catches it with an explicit conflict. For the buyer’s own reservation, I need read-your-writes, enforced by routing that user to the leader for thirty seconds after the hold.

That paragraph names the model, the mechanism, the cost, the anomaly, and the reason. It is the difference between saying the word and understanding it.

Follow-Up Questions to Expect

• “Isn’t a relational database strongly consistent?” A single node, yes. The moment you read from a replica, the read is behind by the replication lag, and the answer depends on which node served it.
• “What does CAP actually say?” During a partition, choose between refusing operations (consistent) and serving possibly stale data (available). It says nothing about the normal case; PACELC does.
• “Linearizable versus serializable?” Linearizable is single-object, real-time ordering across replicas. Serializable is multi-object transaction ordering, with no real-time requirement. Both together is strict serializability, which is what most people mean when they say “strong.”
• “How do you get read-your-writes through a cache?” Write-through, or invalidate on write and carry a version so a stale cache entry is detected. Say that cache-aside alone has a race.
• “Two regions, and writes in both.” Linearizable across regions costs a cross-region round trip per write. Usually the answer is a leader per key in the key’s home region, causal or eventual replication to the other, and a stated staleness bound.
• “Does your managed database do this?” Many managed stores offer a per-request choice between eventually consistent and strongly consistent reads, and some offer session or causal modes. The point is to know what you are asking for and what it costs, not to memorize vendor menus.

Key Takeaways

• Three words spelled “consistency”: ACID invariants, CAP linearizability, and replication models. Say which.
• It is a ladder: strict serializable, linearizable, sequential, causal, session guarantees, eventual. Use linearizable for decisions and session guarantees for what users notice.
• Name the anomaly. “Eventual” means “the user may see X, and here is why that is fine.”
• Match each data item to the weakest model that satisfies it. The display is eventual; the decision is linearizable.
• Point at the mechanism: leader reads, quorums, version tokens, sticky sessions, causal tokens, CRDTs.
• State the cost: a round trip per coordinated operation, unavailability on the minority side of a partition, a leader as a throughput ceiling.
• Isolation and consistency models are different axes. Lost updates and write skew are isolation.

Further Reading

• Jepsen, Consistency Models (the definitive map of the ladder)
• Martin Kleppmann, Designing Data-Intensive Applications, chapters 5, 7, and 9
• Doug Terry, Replicated Data Consistency Explained Through Baseball (the session guarantees, made concrete)
• Peter Bailis, Linearizability versus Serializability
• Daniel Abadi, Consistency Tradeoffs in Modern Distributed Database System Design (the PACELC paper)