Glossary term
Causal Consistency
Engineering definition of causal consistency covering causal order, dependency visibility, read-your-writes, monotonic reads, vector clocks and validation.
Definition
conceptCausal consistency is a distributed consistency model in which operations that may have causally influenced each other are observed in causal order, while independent operations may be observed in different orders.
Causal consistency appears in replicated databases, collaborative applications, session-aware stores, distributed caches, edge systems and message-driven services when the system needs stronger behavior than plain eventual consistency but does not require one global linearizable order. A useful design states the dependency rule, session guarantees, metadata format, read path, write propagation path, conflict policy, lag behavior and validation evidence.
Causal consistency is a distributed consistency model in which operations that may have causally influenced each other are observed in causal order, while independent operations may be observed in different orders. It is stronger than plain eventual consistency and weaker than linearizability.
The model is useful when users expect their own actions and dependent actions to make sense, but the system does not need one global order for every unrelated update. Collaborative editing, social feeds, replicated metadata, edge applications and session-aware stores often need this middle ground.
Causal Order
If operation:
causally precedes operation:
the relationship is written:
Causal consistency requires that any observer who sees:
must also be able to see the effects required by:
The system should not expose an answer that depends on an update while hiding the update that made it possible.
Independent Operations
If neither:
nor:
holds, the operations are concurrent. Different replicas may observe concurrent operations in different orders as long as causal dependencies are preserved.
This is the main difference from linearizability. Linearizability imposes real-time single-copy order. Causal consistency preserves dependency order but avoids forcing a global order on unrelated work.
Session Guarantees
Causal consistency often includes session guarantees. Read-your-writes means a client sees its own completed writes. Monotonic reads mean a client does not move backward after seeing a newer version. Writes-follow-reads means a write issued after a read carries the read dependency forward.
If a client observes version:
and then writes:
the write should carry dependency:
so other replicas know which prior state must be visible before w is exposed.
Metadata
Implementations may use vector clocks, version vectors, dependency sets, session tokens, causal broadcast or per-key histories. If a dependency vector tracks:
replicas and each counter uses:
bytes, metadata is:
For:
the dependency metadata is:
before payload, keys and serialization overhead.
Waiting for Dependencies
A replica may receive operation b before it has received dependency a. If dependency arrival time is:
and request handling time is:
the dependency wait is:
For:
the wait is:
If the system does not wait, it may expose causally incomplete state.
Boundary With Neighboring Models
Eventual consistency promises later convergence but may expose causally surprising states unless session guarantees are added. Causal consistency preserves dependency order but still permits stale or differently ordered concurrent updates. Linearizability preserves real-time order for all operations in the object contract, usually with higher coordination cost.
CRDTs may use causal delivery or metadata, but a CRDT merge rule is not the same as a causal consistency guarantee. A vector clock can help track causality, but the system must still enforce the visibility rule.
When It Fits
Causal consistency fits systems where user intent depends on visible dependency chains but not on a single global order. Examples include comments after a post, replies after a message, configuration updates after a prerequisite change, collaborative edits that reference prior edits, and edge-device state that must preserve local session meaning.
It is a weak fit for scarce inventory, payment debits, exclusive ownership, safety commands and schema migrations where two independent-looking operations may still violate a global invariant. Those cases often need linearizability, consensus, fencing or an explicit rejection path.
Conflict Handling
Causal consistency does not remove conflicts among concurrent operations. It only separates dependent from independent work. Concurrent writes may still require CRDT merge, application merge, last-writer-wins, user reconciliation, idempotency keys or rejection.
The design should state whether conflicts are visible to users, automatically merged, delayed until dependencies arrive, or resolved by a deterministic but lossy rule.
Validation
Validation should include read-your-writes tests, monotonic-read tests, writes-follow-reads tests, delayed dependency delivery, out-of-order replication, session-token loss, multi-device sessions, partition and heal, stale cache reads, concurrent writes and mixed-version clients.
Useful evidence includes dependency metadata, session trace, version vector comparison, causally blocked reads, dependency wait time, stale-read count, conflict count, merge outcome and proofs that no response exposes a dependent update without its prerequisites.
Failure Modes
Common failure modes include dropping session tokens, pruning dependency metadata too early, confusing timestamp order with causal order, applying last-writer-wins to causally related writes, serving cache reads without dependency checks, failing after device switch, and testing only one client against one replica.
A credible causal consistency claim should say exactly which operations carry dependencies, how those dependencies are encoded, what a replica does when dependency evidence is missing and how users are protected from causally incomplete views.