How does distributed tracing work?

WHAT THIS TESTS This probes whether you understand how observability stitches a single logical request back together once it fans out across many independently deployed services.

A GOOD ANSWER COVERS A trace represents the full journey of one request and is identified by a single trace ID created at the entry point. Within that trace, each unit of work is a span identified by a span ID, and each span records a parent span ID, building a tree that captures causality and timing. Context propagation is the mechanism that carries the trace ID and current span ID across process boundaries, typically by injecting them into outbound request headers using a standard like W3C traceparent. The downstream service extracts that context, creates a child span, and continues the chain. Each span records start time, duration, status, and attributes, so the backend can assemble a waterfall view showing where latency accumulated.

COMMON WRONG ANSWERS Treating tracing as merely centralized logging, ignoring the parent-child relationship that makes the tree meaningful, or assuming correlation happens automatically without explicit header propagation. Another mistake is conflating the trace ID and span ID, or claiming sampling is unrelated to tracing.

LIKELY FOLLOW-UPS How does propagation survive async work like message queues? What happens when one service drops the context? How do head-based versus tail-based sampling affect what you actually capture? How do baggage and span attributes differ?

ONE CONCRETE EXAMPLE A user hits an API gateway, which mints trace ID abc123 and span A. It calls the orders service with traceparent containing abc123 and span A, so orders creates child span B and then calls payments, which creates span C. All three spans share abc123 but have distinct span IDs and linked parents. The tracing backend groups them by abc123 and renders a waterfall showing payments span C consumed 400 of the 500 milliseconds, immediately pinpointing the slow hop.