Distributed Context Propagation

Distributed tracing only works if every service in the request path knows it's part of a trace. Service A starts a trace and calls Service B. But how does Service B know the trace exists? How does it know which trace ID to use, which span to set as its parent, and whether the trace is being sampled?

The answer is context propagation, the mechanism for passing trace metadata (and other contextual information) between services. Without it, every service starts its own independent trace, and you end up with hundreds of disconnected single-service traces instead of one unified distributed trace.

Context propagation is the unglamorous plumbing of distributed tracing. Nobody talks about it in conference keynotes. But when it breaks, when one service doesn't forward the context, or two services use incompatible propagation formats, the entire tracing system becomes useless.

Context propagation happens in two directions:

Injection: Before making an outbound call, the tracing library serializes the current trace context into the outgoing request's headers (or message metadata).

Extraction: When receiving an inbound request, the tracing library reads the trace context from the incoming headers and uses it to continue the trace.

For HTTP calls:

Service A creates span → Injects context into HTTP headers → Sends request
Service B receives request → Extracts context from headers → Creates child span → Processes request

W3C Trace Context (the standard):

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: vendor1=value1,vendor2=value2

For message queues: Context is injected into message headers or attributes, not HTTP headers. The consumer extracts context from the message metadata when processing it.

For gRPC: Context travels in gRPC metadata (similar to HTTP headers).