Causal Consistency
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.
What is Causal 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.
What causal consistency actually guarantees
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.
How it works under the hood
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.
When to use it and the trade-offs
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.
A concrete example
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.
Where it is used in production
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.
Frequently asked questions
- How is causal consistency different from eventual consistency?
- 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.
- Is causal consistency the same as read-your-writes?
- 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.
- Can causal consistency be achieved while staying available during a partition?
- 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.
- What handles conflicts between concurrent writes?
- 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.
- Why are vector clocks used to implement it?
- 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.
Learn Causal Consistency hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
See also
Related glossary terms you might want to look up next.
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.