# Causal consistency > Causal consistency preserves the order of operations that depend on one another: if someone reads a message and replies, other readers should not see the reply before its cause is available. It lets replicated systems preserve meaningful ordering without forcing unrelated updates into one global order. Source: https://sysround.com/concepts/causal-consistency Updated: 2026-11-05 ## How causal consistency works Start with the happens-before relationship. Operations in one client's execution are ordered, reading a write creates a dependency on that write, and dependencies are transitive. If Bob reads Alice's message and then replies, Alice's message causally precedes Bob's reply. Independent messages from other users may be concurrent. Track those dependencies explicitly. A client can carry a causal context containing versions it has observed, and attach that context to subsequent requests. Vector clocks, version vectors, or dependency lists are possible building blocks; a wall-clock timestamp alone does not establish causality. Replicas receive updates asynchronously, potentially out of order. Before making Bob's reply visible, a replica checks whether the dependencies in its causal context are satisfied. If Alice's message has not arrived, it buffers the reply or fetches the missing dependency rather than exposing an inconsistent view. Reads must also respect the client's context. If Bob moves to another region after reading Alice's message, that region must serve a sufficiently advanced view, wait for replication, or route the request elsewhere. Dropping the context during failover can break the guarantee. Concurrent writes do not acquire a shared order merely because the system is causally consistent. Two people editing the same value independently still need a conflict policy, such as merging, retaining multiple versions, or a deterministic winner. Causal ordering alone also does not guarantee that replicas eventually converge. ## Worked example: A reply reaches another region before its parent A chat service has replicas in 3 regions. Alice writes message M1 in region A. Bob reads M1 in region B, then sends reply M2 with a causal context that includes M1's version. Replication delivers M2 to region C after 40 ms, but M1 arrives after 120 ms. Region C stores M2 without exposing it during that 80 ms gap. Once M1 is available, it can expose M2. An unrelated message M3 with no dependency on M1 need not wait. If Bob reconnects through region C during the gap, his context requires C to wait, fetch M1, or route his read to a replica that satisfies it. ## Trade-offs - **Less coordination than global ordering.** Unrelated updates can proceed independently, but an operation may still wait for its dependencies to become available. - **Dependency metadata.** Tracking observed versions adds storage, bandwidth, and bookkeeping, especially when dependencies span many writers or partitions. - **Visibility delays.** A locally received update may remain hidden while the replica fetches or waits for a missing predecessor. - **Context must cross boundaries.** Clients, caches, service calls, and asynchronous jobs must preserve relevant causal context or explicitly narrow the guarantee. - **No global freshness or invariant protection.** Causally consistent reads can be stale, and causal ordering does not prevent overselling inventory or concurrent withdrawals. - **Concurrent conflicts remain.** Independent writes can conflict, so convergence requires an additional resolution or merge policy. ## When to use it in a system design interview - A chat or comment system must not display a reply before the message it references. - Collaborative updates depend on earlier edits, and receiving clients need those dependencies before applying them. - A multi-region application can tolerate stale data but not views that contradict operations a user has already observed. - A replicated key-value store needs meaningful cross-key ordering without a total order across all writes. ## How to bring it up in the interview - Name the user-visible invariant first: 'A reply must not become visible before its parent is available.' Then explain why eventual consistency alone permits a bad intermediate view. - Define the scope: one conversation, one document, a session, or multiple keys. Interviewers will probe whether your chosen mechanism actually covers dependencies across shards. - Walk through an out-of-order arrival and a regional reconnect. Explain what context travels with the request and whether the lagging replica waits, fetches dependencies, or redirects. - Separate causal order from conflict resolution and transaction correctness. Expect follow-ups about concurrent edits, stale reads, inventory constraints, and whether linearizability or transactions are needed instead. - Offer a simpler scoped mechanism when appropriate. A per-conversation sequencer may satisfy chat ordering, but it does not automatically provide causal consistency across conversations or services. ## Common mistakes - Treating causal consistency as timestamp sorting; clock order alone cannot tell whether one operation observed another. - Claiming every replica must observe concurrent writes in the same order; causal consistency does not impose that requirement. - Assuming causal consistency guarantees the latest value, atomic multi-key updates, or protection against concurrent invariant violations. - Adding vector clocks but never explaining how reads and replica visibility enforce the tracked dependencies. - Preserving dependencies inside the database while losing them in caches, background jobs, or requests routed to another region. ## Interview questions where it comes up - [Design a chat app like WhatsApp](https://sysround.com/questions/design-whatsapp): Replies, receipts, and cross-region reconnects require an explicit policy for preserving dependencies between messages. - [Design Google Docs](https://sysround.com/questions/design-google-docs): An edit may depend on earlier operations, so replay and live delivery must preserve or explicitly handle those causal dependencies. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Causal consistency is a substantive consistency-model choice when explaining replicated reads, cross-key dependencies, and available writes. - [Design Facebook live comments](https://sysround.com/questions/design-live-comments): Parent-reply visibility and reconnect behavior make causal dependencies central to defining correct comment delivery. ## FAQ ### What is the difference between causal consistency and eventual consistency? Eventual consistency promises convergence if updates stop and replication continues, but by itself does not constrain intermediate views. Causal consistency constrains those views by preserving dependency order. A system can provide both causal consistency and eventual convergence, but they are separate properties. ### How is causal consistency different from linearizability? Linearizability makes operations on an object appear to execute atomically in an order that respects real time. Causal consistency preserves dependency order but can return stale data and leave concurrent operations unordered. It is useful when meaningful ordering matters more than every read reflecting the latest completed write. ### Do vector clocks guarantee causal consistency? No. Vector clocks can represent causal relationships and identify concurrent versions, but they do not enforce which versions clients can observe. The system must also propagate context and gate reads or update visibility until dependencies are satisfied. ## Related concepts - [Eventual consistency](https://sysround.com/concepts/eventual-consistency) - [Vector clocks](https://sysround.com/concepts/vector-clocks) - [Read-your-writes and session guarantees](https://sysround.com/concepts/session-guarantees) - [Linearizability](https://sysround.com/concepts/linearizability) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.