In a context carried with a subscription, where must a value be written for a given stage to read it?

## Two directions inside one pipeline A chain is **written** from the source downward: each operator wraps the one declared before it, and the last thing in the written chain is the subscriber. At that point nothing runs. Work begins when something subscribes, and subscription travels the **other way** — the subscriber asks the operator above it for a subscription, that operator asks the one above it, and so on until the request reaches the source. Only then do values flow back down. A context carried with the subscription is assembled during that upward journey. That single fact answers the whole question: placement in the written chain decides which stages the write reaches, because the write is applied at the moment the subscription passes it. ## What a write contributes, and to whom When the subscription passes an operator that adds an entry, that entry joins the context handed to everything the subscription reaches **afterwards** — everything nearer the **source**. Stages nearer the subscriber were already visited, with the smaller context, and never see it. | the write is placed | stages that can read it | |---|---| | after every stage, at the end of the chain | all of them | | between two stages | the stages between the write and the source | | immediately after the source, at the top | effectively only the source's own work | - A write at the very end of the chain is the safe default: it serves the whole chain. - A write in the middle is a deliberate scoping decision, not a convenience. - A write at the top usually indicates a misunderstanding, because almost nothing reads it. - With two writes of the same key, a stage sees the **nearest** one on its subscriber side, because that is the last write applied before the subscription reached it. - A stage that reads a key nobody wrote gets an absence, not a failure — which is its own defect class. ## The rule that follows Write the context where the subscription is opened: at the boundary that owns the request. That boundary is the one place that genuinely knows the trace identity, the tenant and the caller, and placing the write there — or as the final element of the chain it assembles — makes the entries visible to every stage the chain will ever contain. A library fragment spliced into the middle of someone else's chain should read keys, not write them, precisely because its position decides its audience and it cannot know that position. ## It is a context, not a scratchpad The context is **immutable**: an operator does not mutate it, it derives a new one. Two consequences follow, and both are asked about. 1. A stage cannot use the context to hand a computed value forward to a later stage. The later stage's view was fixed before this stage ever ran, and in the written chain a later stage is *earlier* on the subscription's journey. Data that has to flow forward belongs in the elements — carried alongside the value that produced it. 2. Two subscriptions that share entries cannot interfere with each other. Each derivation produces a distinct value, so a concurrently running subscription on the same worker sees only its own. ## Where ecosystems differ This is the model in which any operator may contribute to the context mid-chain, and it is the model worth being able to reason about, because placement is then a real decision. Other designs fix the context once, where the subscription is opened, and give operators no way to add entries at all; there, placement never arises but the boundary write is mandatory. Both carry the values with the subscription rather than with the worker, which is the property that survives a hop. ## Diagnosing a read that finds nothing When a stage reads a key and finds an absence, work through it in order: 1. Confirm a write for that key exists in the chain at all, rather than in an enclosing scope that never became part of this subscription. 2. Compare positions: is the write nearer the subscriber than the reader? If not, the reader was visited before the entry existed. 3. Check the key itself — an ad-hoc string key spelled differently in two teams' code fails exactly like a missing write. 4. Check what the read is actually reading. A stage reading worker-bound storage rather than the subscription context fails for an entirely different reason and needs a different fix. The interviewer is listening for one sentence: the chain is built downward and subscribed upward, so a context write serves what the subscription reaches after it.