A social app is built as several microservices — posts, comments, notifications — each backed by its own eventually consistent store. A user reads a post, then writes a comment on it, expecting that anyone who can see their comment can also see the post it refers to. What has to happen at the infrastructure level to actually guarantee this writes-follow-reads property across service boundaries, and where does it typically break?

## What the guarantee says Writes-follow-reads, or session causality, says that if a client reads value `X` and then performs a write `Y`, that write is causally dependent on `X`, and any observer of `Y` must also be able to observe `X` or a version at least as new. Within a single service backed by a single data store, this is a comparatively contained problem — the same version-vector or LSN scheme covers all data. In a microservice architecture, though, the read and the dependent write cross service and often data-store boundaries entirely, and a guarantee each individual service offers internally for its own data doesn't automatically compose across those boundaries. ## The chain that has to hold end to end Concretely, for the post, comment, and notification scenario: 1. The user's client calls the posts service, which returns the post along with a **causal marker** — a version number, an LSN, or an entry in a vector clock keyed by post ID. 2. For writes-follow-reads to hold end to end, the client, or more robustly an API gateway or backend-for-frontend layer acting on the client's behalf, must attach that marker to the subsequent write request to the comments service. 3. The comments service must then persist that marker as a causal dependency alongside the new comment record — not just the comment text, but a record that this comment depends on the post being at or beyond that version. 4. Any service or client that later reads that comment must enforce the dependency before exposing it: by checking the posts service or its own cached copy of post state is caught up, by proactively fetching the post fresh before returning the comment, or, in an event-driven model, by attaching the dependency to any downstream event, such as a comment-created event for the notifications service, so every consumer that eventually surfaces the comment can re-validate or wait on the dependency. ## The seams where it breaks This is genuinely expensive to implement correctly, which is precisely why it breaks down at several common seams. - **First, request-context propagation:** many internal RPC frameworks and HTTP clients don't automatically forward custom headers or metadata across service-to-service hops unless every team explicitly wires it in; a causal token attached to the client's original request can silently get dropped the moment it passes through an internal call the comments service makes back to the posts service, or through a shared library unaware of this convention. - **Second, async messaging:** if the comments service publishes an event onto a message bus for the notifications service to consume, the event schema has to explicitly carry the causal dependency; if it's added as an afterthought, older event versions or unrelated consumers silently have no way to honor it. - **Third, caching and CDNs:** if comments are served through an edge cache or read-replica fan-out with no concept of per-item causal dependencies, there is no hook at all for enforcing the dependency at serve time — the cache just returns whatever bytes it has, with no version awareness. - **Fourth, cost and blocking:** even where the mechanism is wired correctly, enforcing block-or-fetch-fresh on every read adds latency, and under partition or heavy replication lag can turn into unbounded waiting, which teams often quietly relax rather than enforce everywhere. ## Why teams scope it narrowly Because of this cost, most production systems don't implement full writes-follow-reads end to end across every service boundary; instead they scope it narrowly to interactions that would be visibly broken if violated, such as a comment thread rendering with a missing parent post, and accept looser guarantees elsewhere, such as push notifications arriving slightly before the referenced content is globally visible being treated as an acceptable, low-stakes artifact. ## Plumbing borrowed from tracing A concrete real-world analog: distributed tracing systems, such as OpenTelemetry's context propagation via trace headers, solve a structurally similar propagation problem — carrying causal or contextual metadata across every service hop, including through async queues — and teams building writes-follow-reads guarantees across microservices often reuse the same context-propagation plumbing, headers through synchronous calls and message attributes through async buses, rather than inventing a separate mechanism, precisely because ensuring propagation survives every hop, including async ones, is already a solved and tested problem in that adjacent space.