Replication & Consistency • Consistency ModelsMedium⏱️ ~3 min
Causal and Session Consistency: Preserving Cause and Effect
Causal consistency preserves cause before effect relationships across the system: if operation A causally precedes operation B (for example, A writes a post and B writes a reply referencing that post), all processes must observe A before B. However, concurrent operations (those without causal relationship) may be observed in different orders by different clients. This model is weaker than linearizability because it does not impose a total real time order on all operations, only on causally related ones. Implementation typically uses version vectors (also called vector clocks) or logical timestamps to track causality, with each client or datacenter maintaining a vector of observed versions. When a client performs an operation, it attaches its current version vector; the system ensures that any replica serving subsequent operations from that client has applied all causally preceding updates.
Session guarantees build on causal consistency to provide intuitive semantics within a client session: read your writes (a client always sees its own updates), monotonic reads (successive reads never return older values), monotonic writes (writes from a session are applied in order), and writes follow reads (writes are ordered after any reads that causally precede them). These guarantees are essential for good user experience: imagine a user updating their profile picture and immediately navigating to their profile page, only to see the old picture because they were routed to a lagging replica. Session consistency prevents this via sticky routing (pinning a session to a specific replica or region), session tokens (small metadata carried with requests indicating the minimum version required), or per session sequence numbers.
Facebook TAO (The Associations and Objects graph store) implements session guarantees for social graph queries, optimizing for read heavy workloads with billions of queries per second. Within a region, TAO provides read after write consistency: a user who likes a post immediately sees that like on refresh. Across datacenters, replication is asynchronous with typical lag of seconds or less, but session continuity is maintained within a region. Azure Cosmos DB exposes session consistency as a distinct level, using session tokens to ensure monotonicity. The failure mode is non sticky routing: if a load balancer sends a client to a different region or replica that has not yet received the client's previous write, session guarantees break silently. Defense requires application level session tokens validated by replicas or sticky routing enforced at the infrastructure layer.
💡 Key Takeaways
•Causal consistency guarantees cause before effect ordering (if A causally precedes B, all processes see A before B) but allows concurrent unrelated operations to appear in different orders across clients
•Session guarantees include read your writes, monotonic reads, monotonic writes, and writes follow reads, preventing time travel and ensuring intuitive user experience within a client session
•Implementation uses version vectors or logical timestamps to track causality, with clients attaching observed versions to requests so replicas can enforce causal dependencies
•Facebook TAO provides read after write within a region for social graph queries (billions per second) with asynchronous cross datacenter replication, typical lag of seconds, and session continuity within regions
•Azure Cosmos DB exposes session consistency via session tokens passed with requests; replicas reject or delay requests that require versions not yet applied, ensuring monotonicity
•Failure mode: non sticky routing breaks session guarantees when load balancers send clients to lagging replicas; defense requires sticky sessions, session tokens, or version based routing at infrastructure layer
📌 Examples
Social media feeds: user posts a comment (write) then refreshes (read); session consistency ensures the user sees their own comment immediately, while other users may see it after asynchronous replication
Collaborative editing (Google Docs style): causal consistency ensures that if user A types a sentence and user B replies to it, all users see A's sentence before B's reply, preserving conversation structure
Shopping cart: user adds item (write) and immediately views cart (read); read your writes guarantee ensures the item appears, even if cart service has multiple replicas with replication lag
Azure Cosmos DB session token: after writing a document with session consistency, client receives token like {region: eastus, lsn: 12345}; subsequent reads include this token to ensure monotonic visibility across replicas