Causal consistency: carry the history a session depends on

If a client reads a post and then writes a reply based on it, that reply depends on the observed post. Program order also relates operations within the defined session model, and transitivity carries dependencies through multiple clients and messages. A causally consistent visibility rule must not expose an update without the relevant causal prerequisites. Concurrent updates have no such ordering relation and may still need a type-specific resolution rule. Causal order is therefore a partial order, not a universal latest value for every key.

A system needs a stated causality scope: objects, partitions, services, and sessions can have different boundaries. Tracking a token for one object does not automatically capture a dependency on another service’s result. Likewise, a client that drops its causal token on reconnect can lose the basis for its session guarantees. An implementation may route to a sufficiently current replica, wait for dependencies, fetch missing context, or explicitly reject the requested guarantee. It cannot simply return a stale value and call the guarantee satisfied.

Read-your-writes requires later reads in the session to reflect its prior writes under the object’s semantics. Monotonic reads prevents a session from moving backward to a history that omits updates it already observed. Monotonic writes preserves the session’s write order at downstream observation. Writes-follow-reads preserves dependencies from what a session read to what it subsequently wrote. They are related obligations but should not be collapsed into one casual phrase such as sticky sessions. Merely revisiting one server may fail after that server loses state or forwards work.

For a fixed-actor prefix model, represent the client’s required history by vector c and a server’s applied history by s. Coverage requires s to dominate c componentwise, assuming those counters describe the same scope and complete prefixes. A server with a larger sum can still miss one required actor’s event. More elaborate systems use dependency checks and metadata specific to their partitioning and replication design. The vector example is a concrete coverage test, not a claim that every causal store uses one global vector.

A disconnected replica that lacks a dependency cannot honestly serve a read requiring that dependency until it obtains the missing information or declines the guarantee. This is a practical availability consequence, even if ordinary local writes remain possible. Causal consistency also does not imply linearizability: two unrelated concurrent writes need not be placed in a real-time total order. Define the user-facing behavior under missing context, and measure how often sessions wait or reroute rather than hiding that cost behind average read latency.

The queue lab illustrates waiting for progress, not causal correctness. Reset, set λ=2 and μ=3, predict the initial backlog of four drains at t=4, then Play or Step. Reset and set λ=4, μ=3 to predict persistent growth instead. The fluid backlog has no actor histories, token checks, or dependency visibility rules. Its value is in separating a waiting-capacity question from the discrete coverage check in the worked example. Faster service does not itself prove that the specific missing dependency arrived.