Context Propagation
Carrying request-scoped identifiers and metadata across every service, thread and asynchronous boundary so a single flow remains traceable end to end.
The mechanism behind both tracing and correlated logging, and the part that actually fails in practice.
One service that does not propagate breaks the chain, and everything downstream of it becomes unattributable — so the value is highly non-linear in adoption. Ninety percent coverage is worth far less than ninety percent of the benefit.
The standard is W3C Trace Context: a traceparent header carrying trace ID, span ID and sampling
decision, plus tracestate for vendor data. Using the standard rather than a bespoke header is what
makes third-party and vendor components participate.
The boundaries where it breaks:
Thread and coroutine handoffs — context stored in thread-local storage is lost when work moves to a pool. Frameworks provide context-aware executors; using them is not automatic.
Asynchronous messaging — the context must be written into message headers by the producer and restored by the consumer, and this is the single most commonly missed case.
Scheduled jobs and batch processes, which have no incoming request and so need a context created deliberately.
Baggage extends the mechanism to arbitrary key-value data — tenant ID, request priority, experiment assignment — propagated alongside the trace. Useful and easy to abuse: everything in baggage is on every request, so it costs bandwidth on every hop.