Skip to main content

Causal Consistency, Eventual Consistency, Session Guarantees

What This Concept Is​

Weaker than linearizability, but stronger than "anything goes." These are the models you actually see in real distributed storage.

Eventual consistency​

If writes stop, all replicas eventually converge to the same value. That is the entire guarantee. It says nothing about when (milliseconds? seconds? hours?) and nothing about what order replicas pass through on the way there. It is the weakest useful model.

Causal consistency​

Operations that are causally related (one could have influenced the other) are observed in the same order by all nodes. Operations that are concurrent can be observed in different orders on different nodes. Causality is captured by Lamport's happens-before relation: operation A happens-before B if A is in the same process before B, or A's effect was read by B, or by transitivity.

Causal consistency prevents the paradoxes of "Alice asks a question, Bob answers, but Carol sees Bob's answer before Alice's question." It allows concurrent operations to reorder freely.

Session guarantees (Bayou system)​

Four guarantees, named by Terry et al. (Bayou, 1994), that a client's own session observes even in an eventually-consistent system:

  1. Read your writes (RYW): after you write, you will see your own write on subsequent reads from the same session.
  2. Monotonic reads (MR): successive reads do not go backwards in time. If you saw version v, you will never see a version older than v.
  3. Monotonic writes (MW): your writes are applied in the order you issued them.
  4. Writes follow reads (WFR): if you read a value and then do a write that depends on it, other nodes that see your write will have already seen the value you read.

These are weaker than linearizability or causal consistency but easy to implement on top of eventually consistent stores via client-side sequence numbers or session tokens.

Why It Matters Here​

Real systems rarely give you linearizability; they give you some combination of these. DynamoDB defaults to eventual consistency with optional session guarantees. Cassandra offers tunable consistency where you can dial knobs that correspond roughly to session guarantees at the quorum level. COPS, Eiger, and Redis (in some configurations) offer causal consistency. Knowing exactly which model a system provides - and how to translate it into application-visible behavior - is what separates a correct integration from a hidden-data-corruption integration.

Concrete Example​

Three replicas, each receiving writes from users. The application: a social feed with posts and replies.

  • Eventual consistency only: Alice posts "lunch?" to replica R1. Bob's client hits R2, does not see Alice's post yet, then Alice's post replicates. Bob posts "sure!" (a reply). Carol's client on R3 receives Bob's post before Alice's and sees an orphaned reply. This is a causal violation.
  • Causal consistency: the system tracks that Bob's reply "sure!" depends on Alice's "lunch?" Bob's reply cannot be shown at R3 until R3 has Alice's post.
  • Session guarantees only: Alice's own session shows her post (RYW). Bob's session sees posts he has already seen (MR). But cross-session causality between Alice and Bob is not guaranteed unless the system also tracks causality or session tokens chain across users.
  • Linearizable: every node sees one global order of posts and replies, respecting real-time order.

Another classic: a user uploads a photo (to R1) then navigates to their profile (routed to R2). Without RYW, they see "no photos yet." With RYW, they always see the photo they just uploaded.

Common Confusion / Misconception​

"Eventual consistency is too weak for anything real." It is the basis of every production cache, every asynchronously replicated read replica, and every CDN. The point is to layer session guarantees and explicit coordination on top when correctness requires it.

"Causal consistency is like linearizability but weaker." It is weaker and different. Linearizability respects real-time order; causal consistency respects only the causality relation. Two independent writes in real time can appear in any order under causal consistency.

"RYW is automatic." It requires either session affinity (routing the same session to the same replica), client-tracked version vectors, or session tokens forwarded through the stack. None of this happens for free.

"Monotonic reads means I always get the latest value." No. It means I never go backwards. I might see version 3, then version 3 again, then version 5. I will never see 3, then 2.

How To Use It​

For every cross-replica read in your system, ask:

  1. Does this read need to see the user's own recent writes? -> RYW.
  2. Does this read appear in a sequence where going backwards would be confusing or wrong? -> MR.
  3. Does a write depend on a prior read in the same session? -> WFR.
  4. Do writes from the same user need to arrive in order? -> MW.
  5. Does a write from user A need to appear only after dependencies it depended on (posts before replies)? -> causal consistency.

Most consumer apps are happy with session guarantees. Feeds and collaborative tools often need causal. Locks, leader election, and unique constraints need linearizable.

Check Yourself​

  1. Give one concrete anomaly that causal consistency prevents but eventual consistency allows.
  2. State each of the four session guarantees in one sentence.
  3. Why is causal consistency "not quite" enough for a feed application? Give an example it does not prevent.
  4. What is the difference between "eventual consistency" and "bounded staleness"?
  5. Can a system provide linearizability for one object and only eventual consistency for another? Why or why not?

Mini Drill or Application​

For each application, name the weakest consistency model that would still be correct:

  1. A "last updated" timestamp on a user's profile, shown in their own UI.
  2. A comment thread where replies quote the parent.
  3. A shopping cart (one user, possibly multiple devices).
  4. A leader-election lock across microservice replicas.
  5. A follower count displayed on a public profile page.

Read This Only If Stuck​