Practice the vocabulary of stitching a distributed trace together across many service boundaries.
0 / 5 completed
1 / 5
At standup, a dev mentions passing a standardized trace and span identifier between services so a distributed trace can be stitched into one coherent view spanning multiple service boundaries. What is this practice called?
Trace context propagation passes a standardized trace and span identifier between services so a distributed trace can be stitched into one coherent view spanning multiple service boundaries. Each service recording its own independent, unlinked trace produces a set of disconnected fragments rather than one unified picture of a request's full path. This propagation is what makes a distributed trace actually useful for understanding true end-to-end latency across many services.
2 / 5
During a design review, the team wants each new span created by a downstream service to be recorded as a child of the span it was called from, preserving the caller-callee relationship in the resulting trace. Which capability supports this?
A parent-child span relationship preserved across a network call records a downstream service's new span as a child of the span it was called from, keeping the caller-callee structure intact in the resulting trace. Recording every span as an unrelated, top-level entry loses that structure, making it hard to see which call actually triggered which. This preserved relationship is what gives a distributed trace its coherent, navigable tree shape.
3 / 5
In a code review, a dev notices a queue consumer explicitly extracts the trace context carried inside a message and continues the same trace, rather than starting a brand-new, disconnected trace for that message. What does this represent?
Trace context propagation across an asynchronous queue boundary has the consumer explicitly extract the trace context carried inside a message and continue that same trace, rather than starting an entirely new, disconnected one. Starting a brand-new trace for every consumed message severs the connection back to whatever originally produced that message. This explicit extraction is necessary because an async boundary has no in-process context to rely on automatically, unlike a direct synchronous call.
4 / 5
An incident report shows a distributed trace broke into two disconnected fragments because a queue consumer didn't extract and continue the trace context carried in the message, hiding the true end-to-end latency of that request. What practice would prevent this?
Explicitly extracting and continuing the trace context carried in a queue message at the consumer prevents exactly the kind of broken, fragmented trace this incident describes. Starting a new trace with no extraction hides the true end-to-end latency, since the two fragments look like entirely separate requests. This explicit continuation is essential wherever a trace needs to cross an asynchronous, queue-based boundary.
5 / 5
During a PR review, a teammate asks why the team standardizes on a common trace context propagation format instead of letting each team invent its own custom tracing header. What is the reasoning?
A standardized propagation format lets a service owned by any team, or even an external vendor, interoperate within one unified trace, since every participant understands the same shared header format. A custom, per-team header only works reliably within that team's own services and breaks the moment a trace crosses into a service that doesn't recognize it. The tradeoff is the upfront coordination needed to adopt a shared standard across every team and service in the system.