Trace context and propagation across services

WHAT THIS TESTS This probes whether you understand the specific propagation mechanism, especially the trace context and the standardized headers, that makes cross-service correlation actually work.

A GOOD ANSWER COVERS Distributed tracing correlates a request by giving the whole request one trace ID and modeling each operation as a span with its own span ID and a parent span ID, forming a tree. The piece that makes this work across process boundaries is trace context: a compact set of identifiers, including the trace ID, the current or parent span ID, and trace flags such as whether this trace is sampled, plus optional vendor state. When one service calls another, the tracing instrumentation injects this context into the outbound request, conventionally as HTTP headers following the W3C Trace Context standard, namely traceparent for the core identifiers and tracestate for vendor-specific data. The receiving service extracts the incoming context, creates a child span whose parent is the caller's span and whose trace ID matches, does its work, and injects updated context into any further downstream calls. Every service exports its spans to a backend, which groups them by trace ID and reconstructs the full tree.

COMMON WRONG ANSWERS Assuming correlation happens automatically without explicitly propagating headers, or thinking each service generates an independent trace ID. Forgetting the sampled flag must propagate so the whole trace is consistently kept or dropped, and ignoring async paths like queues where context must be carried in message metadata.

LIKELY FOLLOW-UPS What exactly is in the traceparent header? How does propagation survive message queues or async work? What breaks if one hop drops the header? How does the sampled flag coordinate sampling across services?

ONE CONCRETE EXAMPLE A gateway receives a request, creates trace ID t1 and span s1, and calls the orders service with a traceparent header carrying t1, s1, and the sampled flag. Orders extracts it, creates span s2 with parent s1 under trace t1, then calls payments, injecting t1 and s2. Payments creates s3 under t1. All three export spans tagged with t1, and the backend assembles them into a single waterfall, even though three independent processes handled the request.