cross-service causal tokens
Parent: Causal Consistency · Published reference · snapshot 2026-10-15
↓ Facts as markdownall context files
Depth-first rabbithole dossier for cross-service causal tokens; source-anchored research pack.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- [low] Causal consistency is not limited to snapshot reads and applies across read concern levels, ensuring later reads observe at least the effects of earlier writes regardless of which replica serves the read. Sources: https://dev.to/franckpachot/read-your-writes-on-replicas-postgresql-wait-for-lsn-and-mongodb-causal-consistency-4he2 [source]
How it works
- [low] Causal consistency guarantees that if process A communicates an update to process B, subsequent access by B returns the updated value, and writes supersede earlier writes, while unrelated processes follow eventual consistency rules. Sources: https://www.allthingsdistributed.com/2008/12/eventually_consistent.html [source]
- [low] Session consistency is a practical version of causal consistency where a process accesses storage in a session context, guaranteeing read-your-writes consistency as long as the session exists. Sources: https://www.allthingsdistributed.com/2008/12/eventually_consistent.html [source]
- [low] A write W1 with write concern majority can only succeed when applied to a majority of nodes, and the causal read R1 with read concern majority waits to see T1 majority committed before returning success. Sources: https://mongodb.com/blog/post/casual-guarantees-anything-casual [source]
- [low] With read concern local, the causal read R1 may occur on either the P1 or P2 timeline; when it runs on P1 it may not see a write that was majority committed on the true primary's timeline, breaking read your own writes. Sources: https://mongodb.com/blog/post/casual-guarantees-anything-casual [source]
Problems, failure modes and limitations
- [low] If a session terminates due to a failure scenario, a new session must be created, and causal consistency guarantees do not overlap between sessions. Sources: https://www.allthingsdistributed.com/2008/12/eventually_consistent.html [source]
- [low] MongoDB recommends using both read concern majority and write concern majority to preserve causal guarantees and durability across all failure scenarios. Sources: https://mongodb.com/blog/post/casual-guarantees-anything-casual [source]
Comparisons and alternatives
- [low] Causal consistency is a consistency model for distributed databases that guarantees causally related operations are observed in the same order, allowing clients to wait only for dependent operations rather than a total order. Sources: https://jepsen.io/analyses/mongodb-3-6-4 [source]
Facts and statements
- [low] Causal consistency tokens are cryptographically signed to prevent malicious clients from pushing nodes too far into the causal future, which would prevent them from servicing further operations. Sources: https://jepsen.io/analyses/mongodb-3-6-4 [source]
- [medium] MongoDB implemented causal consistency in version 3.6 (2017), using a hybrid logical clock based on the Lamport logical clock to establish a global partial ordering of events across replica sets and sharded clusters. (verified as of 2026-10-15) Sources: https://emptysqua.re/blog/how-to-use-mongodb-causal-consistency/, https://mongodb.com/blog/post/casual-guarantees-anything-casual [source]
- [low] In the limiting case where every session performs only a single operation, timestamps can be manually threaded from session to session to construct arbitrary directed acyclic graphs (DAGs) of causal relationships. Sources: https://jepsen.io/analyses/mongodb-3-6-4 [source]
- [low] Writes that must occur after read operations are executed after those read operations, ensuring causal ordering between reads and writes. Sources: https://jepsen.io/analyses/mongodb-3-6-4 [source]
- [high] To guarantee causal consistency in the presence of node failures or network partitions, both read concern and write concern must be set to "majority". Sources: https://www.mongodb.com/docs/manual/reference/read-concern.md, https://emptysqua.re/blog/how-to-use-mongodb-causal-consistency/, http://muratbuffalo.blogspot.com/2024/04/implementation-of-cluster-wide-logical.html [source]
- [low] In the absence of node failures or network partitions, causal consistency is guaranteed by all configurations, including read concern local and write concern w1. Sources: http://muratbuffalo.blogspot.com/2024/04/implementation-of-cluster-wide-logical.html [source]
- [low] A token can be used to force one session to observe the results of another, preserving causal ordering. Sources: https://jepsen.io/analyses/mongodb-3-6-4 [source]
Related concepts
- causal — is a part of cross-service causal tokens
- tokens — is a part of cross-service causal tokens
Children
- No children recorded.