System Design Data
Consistency Models
You edit your bio in Mumbai and immediately see the new text. A friend in São Paulo still sees the old bio for a second. Inventory decrement on checkout must not allow two buys of the last item. Those are different on the same product—not one global “strong” or “eventual” sticker.
This note is a taxonomy: , sequential, , , and the session family (, , ). Use it to name the contract; deeper repair and CRDT mechanics belong elsewhere.
Pick by damage if wrong
Latest value or error; no silent fork.
Cause before effect; concurrent OK to diverge briefly.
Writer must see their own edit.
Converge later; name the staleness window.
What actually happens
When data lives on one machine, “read the latest write” is almost free. When data is replicated for latency and availability, replicas disagree for a while unless every write waits for coordination. A is the language for which disagreements are allowed. forbids serving a completed write’s past; allows temporary past until convergence; sits between by respecting happened-before without requiring a single global real-time order.
Users experience consistency through sessions. stops the “I saved and it vanished” bug. stop time travel when a load balancer hops replicas. keep one client’s updates ordered. Together these are : much cheaper than cluster-wide linearizability, often enough for UX.
Do not confuse this ladder with ACID “consistency” (constraints) or with . CAP C is about partition-time linearizable behavior. The taxonomy here is what you quote when an interviewer asks “how consistent is this read?”
How to choose a model
1. What breaks if stale? Money and unique inventory → lean linearizable. Like counts → eventual or bounded staleness.
2. Does causality matter? Replies, reactions, collaborative edits → causal or consistent prefix.
3. Is the pain per session? If only the writer is confused, add RYW / monotonic before paying for global strong reads.
Simple rule of thumb
Decide per operation. Default to the weakest model that keeps the product honest. Publish a when you choose eventual. Never say “eventually consistent” without naming who may lag and how conflicts merge.
The strength ladder
Strength roughly tracks coordination cost. Session guarantees can be layered on top of an eventually consistent store.
Read the diagram definition
flowchart TD
L[Linearizability] --> S[Sequential consistency]
S --> C[Causal consistency]
C --> Sess[Session guarantees: RYW / monotonic]
Sess --> E[Eventual consistency]
L -.->|strongest / costliest| Cost[Coordination latency]
E -.->|weakest / cheapest| Cost
RYW for the writer, lag for the friend
Same write, two models: the author gets read-your-writes; a distant reader may still see eventual lag until catch-up—then monotonicity forbids sliding backward.
Read the diagram definition
sequenceDiagram
participant A as Client A writer
participant P as Primary / region A
participant R as Lagging replica
participant B as Client B friend
A->>P: Write profile bio
P-->>A: Ack
A->>P: Read own profile
P-->>A: New bio (RYW)
B->>R: Read profile
R-->>B: Old bio (allowed under eventual)
Note over R: Replication catch-up
B->>R: Read again
R-->>B: New bio
Note over A,B: Monotonic reads: B must not later see old again
Taxonomy at a glance
| Model | Promise | Typical fit |
|---|---|---|
| Linearizability | Single-copy real-time semantics | Payments, locks, unique inventory |
| Sequential | One global order; may lag real time | Some multiprocessor / coordination settings |
| Causal | Respect happened-before | Comment threads, collaborative apps |
| Session (RYW / monotonic) | Per-client UX guarantees | Profile editors, sticky dashboards |
| Eventual | Converge if writes stop | Feeds, DNS-like lookups, counters |
| Bounded staleness | Lag capped by time/version | Dashboards with freshness SLOs |
Strong models: linearizability and sequential
is the gold standard for “acts like one machine.” After a write returns success, any read that starts later must observe it (or a newer value). Cross-region linearizable commits often pay tens to hundreds of milliseconds of coordination. That cost is why money paths use it selectively.
still requires a single order agreeing with each process’s program order, but that order need not respect real-time across clients. In distributed product interviews, people often say “strong” when they mean linearizable; clarify which one you need.
Causal consistency and consistent prefix
If Alice posts a photo and then comments “look!”, says nobody should see the comment without the photo. Concurrent likes from Bob and Cara may appear in either order. Tracking causality uses version vectors, dependency metadata, or session tokens—not full consensus on every write.
is the “no holes” sibling: you may be behind, but the history you see is a valid prefix of the causal order. Both sit above raw eventual, where even causal order can be violated until repair finishes.
Session guarantees in detail
Read-your-writes
After a client’s write succeeds, its subsequent reads see that write. Implementations: sticky to primary, “read your region,” or pass a version watermark the replica must meet. Friends can still lag.
Monotonic reads
Never go backward in observed versions for one client. Sticky replica, client-side high-water mark, or coordinator that tracks last-seen version. Failover that ignores the mark is a common bug.
Monotonic writes
Writes from one client apply in issue order. Needed when clients retry or fan out updates. Per-client sequence numbers or a single writer per key enforce it.
Writes-follow-reads / consistent prefix flavor
If a client reads x and then writes y, y is ordered after x in the visible history. Prevents “reply without seeing the parent” for that session’s subsequent writes.
Eventual and bounded staleness (placement only)
promises convergence, not a deadline. In interviews, always add: who can be stale, max acceptable lag, and conflict policy. is the product-friendly middle: “reads within 5 seconds of latest” without full linearizability.
Mechanisms (anti-entropy, quorums, CRDTs, LWW) are how you implement weaker models. This taxonomy stops at the contract so you do not confuse “eventual” the label with a specific storage design.
Failure timeline: one product, three models
T0 User buys last seat: inventory path uses linearizable decrement T1 Same user edits profile: RYW sticky read to writer region T2 Friend opens feed: eventual replica + 3s cache; sees old like count T3 Friend refreshes: monotonic reads → count only moves forward T4 Bad design: inventory also "eventual" → two buyers of last seat Outcome Models are per operation; mixing them is normal and necessary
Break the improved design
Session stickiness dies on mobile networks and multi-device logins unless version watermarks travel with the user. Causal metadata balloons if every object tracks unbounded dependency history. Calling a leader-based store “linearizable” without safe read paths (stale leader, non-linearizable follower reads) mislabels the model.
Bounded staleness without measuring replication lag is fiction. Clients that retry across regions without monotonic tokens observe time travel even when the store is fine.
Trade-offs
Linearizability vs availability and latency
Linearizable writes often wait for quorum or cross-region consensus. That latency and partition unavailability are the price of single-copy semantics. Use them where forks cost money or trust; elsewhere prefer weaker models.
Causal tracking vs metadata overhead
Causal consistency needs dependency information. Fine-grained tracking is precise and expensive; coarse sessions are cheaper and miss some edges. Choose based on whether missing a cause-before-effect is a product bug.
Session guarantees vs global strong reads
RYW and monotonic reads fix the loudest UX bugs at low cost. They do not protect two different users from seeing divergent states. Know when session-only is enough and when inventory still needs a strong path.
Eventual simplicity vs explicit staleness contracts
“Eventual” is easy to say and incomplete. Bounded staleness, conflict rules, and UX for syncing states turn it into an engineering contract. Prefer naming the bound over hoping replicas are “usually fast.”
Taxonomy models vs CAP C
CAP consistency is a partition-time linearizability-style property. Day-to-day model choice (causal vs RYW vs eventual) still matters when the network is healthy. Use both vocabularies; do not collapse them into one slide.
Choosing and explaining consistency models
A complete explanation connects the mechanism to a requirement. Describe what improves when you introduce it, which new failure cases become possible, and how you would know that the trade-off is worthwhile.
Explain the core idea
I pick a consistency model per operation from the damage of being wrong, not one label for the whole product.
Linearizability for money and unique inventory; causal for threaded interactions; session guarantees for writer UX; eventual with a named staleness bound for feeds and counts.
I distinguish ACID consistency, CAP C, and this read/write taxonomy so the interviewer hears precise language.
When it belongs
Replication, multi-region, or caching appears in the design.
The interviewer asks how strong the reads are.
You need to justify why one path waits for quorum and another does not.
How it fails
Clients observe time travel without monotonic reads.
Writers think updates vanished without RYW.
Mislabeling follower reads as linearizable.
Trade-offs to weigh
Coordination latency versus freshest-value guarantees.
Causal metadata cost versus cause-before-effect UX.
Session-only fixes versus true multi-reader agreement.
Common misunderstandings
Saying the database is “strongly consistent” without naming the model.
Using eventual consistency for inventory without compensating controls.
Cloning CAP slogans instead of stating the user-visible contract.
Wrap-up
You now have a ladder from linearizability down to eventual, plus the session guarantees that make weaker stores feel sane. Practice assigning models to concrete product actions.
Exercises
- Assign models. For a social app: like count, profile bio, password change, comment reply. Name the model and one sentence why.
- Session vs strong. A user edits a doc on phone and immediately opens laptop. Which guarantees fail with sticky-IP RYW only? What token would you pass?
- Causal hole. Draw a history where eventual allows seeing a reply without its parent, and show how causal forbids it while still allowing concurrent sibling comments to reorder.
Primary sources
- Jepsen consistency models : precise definitions and diagrams.
- Terry et al., Bayou : session guarantees.
- Bailis et al. on causal consistency : practical causal systems.
Key takeaway
Consistency models are contracts on the ladder from linearizability to eventual. Mix them by operation: strong where forks hurt, causal where order of cause matters, session guarantees for writer UX, and eventual only with an explicit staleness and merge story.