We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Consistency Models
A consistency model that preserves cause-and-effect ordering: if operation A causally precedes B, all nodes see A before B. Weaker than linearizability but stronger than eventual consistency.
In short
Causal consistency is a consistency model that guarantees operations which are causally related are seen in the same order by every node, while operations with no causal link can be seen in any order. If a write B depends on a write A (for example, a reply that depends on the original comment), no process will ever observe B without first observing A. It is weaker than linearizability but stronger than eventual consistency.
In short
Causal consistency is a consistency model that guarantees operations which are causally related are seen in the same order by every node, while operations with no causal link can be seen in any order. If a write B depends on a write A (for example, a reply that depends on the original comment), no process will ever observe B without first observing A. It is weaker than linearizability but stronger than eventual consistency.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Causal Consistency across a run of lessons, not one page. These 4 alone are about 85 minutes of step-by-step reading, every one with a quiz.
If A causes B, everyone sees A before B, preserving cause-and-effect in distributed systems.
The strongest consistency guarantee, every operation appears to take effect at a single instant.
All nodes see operations in the same order, though not necessarily real-time order.
The full spectrum from eventual to strong, understand every model and when you need each one.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Causal Consistencypay once,
yours for life
Two operations are causally related when one could have influenced the other. There are three ways this happens. First, if a single process does A and then B, A causally precedes B. Second, if a process reads a value and then writes a new one, the write depends on the read. Third, causality is transitive: if A precedes B and B precedes C, then A precedes C. Everything else is concurrent, meaning neither operation knew about the other.
The model promises that every node applies causally related writes in the same order. Concurrent writes carry no ordering promise, so two replicas are free to apply them in different orders. This is why causal consistency sits in the middle of the spectrum. Linearizability gives a single global order for all operations and behaves like one machine. Eventual consistency gives no order at all and only promises replicas converge someday. Causal consistency orders the things that matter for correctness and leaves the rest free.
A useful mental check: if you would be confused or upset to see the effect without the cause, that pair is causally related and the model protects it. A reply appearing before the comment it answers, a balance update appearing before the deposit that caused it, a photo showing up before the album it was added to. Those anomalies cannot happen under causal consistency.
The standard mechanism is tracking dependencies with vector clocks or dependency lists. Each write is tagged with metadata describing the writes it depends on. When a replica receives a write, it does not make it visible to readers until every dependency has already been applied locally. If a dependency is missing, the write waits. This is the core trick, and it is why causal systems can serve reads from any nearby replica without blocking on a coordinator.
Vector clocks are the classic tool. Each node keeps a counter per node in the cluster. An operation's clock captures what that node had seen at the moment of the write. Comparing two clocks tells you whether one happened before the other or whether they are concurrent. Real systems trim this metadata aggressively because per-key vector clocks get expensive at scale, so production designs like COPS use explicit nearest-dependency lists instead of full vectors.
Because each replica only needs to wait for dependencies, not for a global agreement round, writes are accepted locally and replicated asynchronously. That keeps writes fast and keeps the system available during network partitions, which is the main reason the model is attractive.
Reach for causal consistency when users interact across replicas spread over regions and you want low latency plus availability, but you cannot tolerate nonsensical ordering. Social feeds, comment threads, collaborative documents, messaging, and shopping carts are good fits. The classic motivating example is a comment system where a reply must never appear before the message it replies to.
The trade-off is that concurrent writes still conflict and you must resolve them yourself. If two users edit the same field at the same time with no causal link, the model lets both happen and you decide the winner using last-writer-wins, application merge logic, or CRDTs. Causal consistency orders dependent operations but does not eliminate the need for conflict resolution on truly concurrent ones.
It is also not strong enough for invariants that span keys and require a global view, like enforcing that a bank account never goes negative across concurrent withdrawals at different replicas. That needs linearizability or a transaction. And the dependency metadata has a real cost in memory and bandwidth, which is why most deployments cap or compress it.
Picture a photo sharing app with replicas in Virginia and Singapore. A user in Virginia uploads a photo, then removes their boss from the access list, then writes a status that says the photo is now private. These three writes are causally linked because each followed the previous one on the same session.
Under eventual consistency, the Singapore replica might apply the status write before the access change replicates. For a moment the boss could still see a photo the user believes is hidden. Under causal consistency the status write carries a dependency on the access change, so Singapore holds the status update until the access change arrives. The cause always lands before the effect.
Meanwhile a completely unrelated user in Singapore liking a different photo is concurrent, carries no dependency, and replicates freely without waiting. That separation between ordered and unordered operations is exactly what makes the model both correct enough and fast enough for global apps.
MongoDB
Causal consistency sessions let a client read its own writes and see monotonic reads across replica set members by passing operation time and cluster time tokens between operations.
Facebook TAO and academic COPS
COPS, the research system from Facebook collaborators, pioneered scalable causal consistency for geo-replicated key value stores using explicit dependency tracking.
Azure Cosmos DB
Offers a consistency level called consistent prefix plus session consistency that gives causal guarantees, ordering reads and writes within a client session across regions.
AntidoteDB
A research and production geo-replicated database built around causal consistency combined with CRDTs so concurrent writes merge automatically.
Eventual consistency only promises that replicas converge to the same state eventually, with no ordering guarantee along the way, so an effect can briefly appear before its cause. Causal consistency adds the rule that any two operations with a cause-and-effect relationship are seen in that order everywhere, while still allowing concurrent operations to be reordered.
Read-your-writes is one of the session guarantees that causal consistency includes, but causal consistency is broader. It also covers monotonic reads, monotonic writes, and writes-follow-reads, and it spans dependencies across processes, not just a single user's own session.
Yes, and that is its big selling point. Causal consistency is the strongest consistency model that can be provided in an always-available, partition-tolerant system, because writes are accepted locally and only delayed until their dependencies arrive, never until a global coordinator agrees.
Causal consistency does not resolve them for you. Operations with no causal link can be applied in different orders on different replicas, so you need a resolution strategy such as last-writer-wins timestamps, application-level merging, or conflict-free replicated data types that merge deterministically.
Vector clocks capture the happened-before relationship precisely. By comparing two clocks you can tell whether one operation causally preceded another or whether they were concurrent, which is exactly the information a replica needs to decide whether it must wait for a dependency before making a write visible.
Eventual Consistency
A consistency model where updates propagate asynchronously and all replicas will eventually converge to the same value. Trades immediacy for availability.
Vector Clock
A logical clock that tracks causality across distributed nodes using a vector of counters. Each node increments its own counter and merges vectors on message receipt.
Lamport Timestamp
A simple logical clock where each event increments a counter. If event A causes event B, A's timestamp is always less than B's. The foundation of logical time in distributed systems.
Strong Consistency
A guarantee that after a write completes, all subsequent reads will return the updated value. Safer but slower than eventual consistency.
Linearizability
The strongest consistency guarantee: every operation appears to take effect atomically at some point between its invocation and completion. As if there's a single copy of the data.
Serializability
A guarantee that concurrent transactions produce the same result as if they were executed one at a time in some serial order. The gold standard for database transaction isolation.
This page explains the idea. The "Causal Consistency" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Causal Consistency lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Causal Consistency in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
