"Consistency models: strong vs eventual and everything between"
What consistency guarantees actually mean: linearizability, serializability, sequential and causal consistency, read-your-writes, monotonic reads, bounded staleness and eventual consistency, with examples of which product features need which, and what each costs.
Reading is half of it. See this used in a real interview: walk through Design a Distributed Key-Value Store →
"Strong or eventual consistency?" is asked in nearly every system design interview, but the real world has many levels between the two, and naming the right one is more convincing than picking an extreme. A news feed, a bank balance, a chat thread and a profile edit each need a different guarantee. This guide defines the common models, what users would notice without them, and what they cost.
The spectrum
From strongest to weakest, roughly:
| Model | Guarantee | Example need |
|---|---|---|
| Linearizability | every operation appears to take effect instantly at one point between its start and end; everyone sees the same latest value | locks, leader election, unique usernames, inventory decrements |
| Sequential consistency | all nodes see operations in the same order, consistent with each client's order, but not necessarily real time | replicated state machines without real-time needs |
| Causal consistency | operations that are causally related are seen in that order by everyone; unrelated ones may differ | comments appear after the post they reply to; chat replies after questions |
| Read-your-writes | a user always sees their own writes | after editing your profile, you see the edit |
| Monotonic reads | a user never sees data go backwards in time | a refresh never shows an older feed than the last one |
| Bounded staleness | reads are at most T seconds or N versions behind | dashboards, analytics, "close enough" counts |
| Eventual consistency | if writes stop, replicas converge eventually | like counts, view counts, recommendations |
The middle levels (read-your-writes, monotonic reads, causal) are called session guarantees; they give users a sensible experience at much lower cost than linearizability.
Linearizability versus serializability
Often confused:
- Linearizability is about single objects and real time: a read returns the latest completed write.
- Serializability is about transactions over multiple objects: the result equals some serial order of the transactions, which need not match real time.
- Strict serializability combines both (Spanner provides it).
See transactions and isolation.
What users notice without them
- No read-your-writes: you post a comment, refresh, and it is gone (read from a lagging replica). Users post it again.
- No monotonic reads: a message appears, disappears on refresh, then reappears, as requests hit different replicas.
- No causal consistency: someone sees a reply before the message it answers.
- No linearizability: two people both register the username "alex", or the last ticket sells twice.
How to provide them
- Linearizable: a single leader for the key (reads from the leader, with leases), or consensus (Raft, Paxos) per range. See how Raft works.
- Read-your-writes: route a user's reads to the leader for a short time after they write, or carry the write's version or log position and read from a replica that has caught up to it. Cache the user's own recent writes on the client.
- Monotonic reads: pin a user's session to one replica, or pass the last seen version so replicas behind it are skipped.
- Causal: track dependencies with version vectors or hybrid logical clocks, or keep causally related data in one partition (one chat in one partition with sequence numbers). See unique ids, ordering and time.
- Bounded staleness: monitor replication lag and route around replicas that fall behind.
- Eventual: asynchronous replication, with conflict resolution (last-writer-wins, merges, CRDTs). See quorums and leaderless replication.
Costs
Stronger guarantees require coordination:
- Latency: a majority round trip per write (and sometimes per read); across regions, tens to hundreds of milliseconds.
- Availability: during a partition, a linearizable system must refuse some requests. See CAP theorem.
- Throughput: leaders and consensus groups become bottlenecks without partitioning.
Weaker models are faster and more available but push complexity into the application (conflicts, anomalies).
Mixing levels in one design
Real systems choose per feature:
- Payments and balances: linearizable or serializable transactions in one region or a consensus-replicated database. See Design a Payment System.
- Inventory and bookings: linearizable decrements or constraints on a single key.
- Chat: causal order within a conversation via per-conversation sequence numbers; read-your-writes for the sender.
- Feeds: eventual, with read-your-writes for the user's own posts and monotonic reads to avoid flicker. See Design a News Feed.
- Counters: eventual.
- Collaborative editing: eventual convergence with CRDTs or OT, preserving intent. See Design Google Docs.
In the interview
Instead of "we use eventual consistency", say: "Feeds are eventually consistent with read-your-writes for the author, implemented by reading the author's own timeline from the primary for a minute after posting; payments use serializable transactions on the primary; the username table enforces uniqueness with a unique constraint." Precise and cheap.
Checklist
- Name the model per feature, not one for the whole system.
- Linearizability only where correctness demands it.
- Session guarantees (read-your-writes, monotonic reads) for good user experience.
- Causal order where replies and threads matter.
- Know the mechanism for each: leaders, consensus, versions, session pinning.
- State the latency and availability cost of strong guarantees.