operations
Distributed Tracing
Follow a single user request across many services and see where time is actually spent.
In a monolith, when a request is slow you read one stack trace and one log file. In a microservices system, a single user action might fan out across a dozen services, and each one only knows about its own slice — so "why was this request slow?" or "where did it fail?" becomes nearly impossible to answer from isolated, per-service logs. Distributed tracing reconstructs the full journey of one request across every service it touched, turning a scatter of disconnected logs into a single coherent timeline.
A parcel tracking number: one id follows your package through every depot and truck, so you can see exactly where it is and which leg was slow.
Key Concepts
1
It works by propagating context. When a request enters the system, it is assigned a unique trace id, and that id is passed along in headers to every downstream service it calls. Each unit of work — a service handling the request, a database query, an outbound call — records a span: a timed operation tagged with the trace id and its parent span, plus metadata. Collected together, the spans for one trace id assemble into a tree that shows the entire request flow: which services were involved, in what order, how long each took, and where errors occurred. Visualised as a waterfall (in Jaeger, Zipkin, or a commercial APM), this immediately reveals the slow hop, the unexpected extra call, or the service that threw. OpenTelemetry has become the vendor-neutral standard for instrumenting code and propagating this context, so you can switch backends without re-instrumenting.
2
The essentials interviewers expect are the vocabulary — trace, span, and context propagation via headers — and why it is indispensable for latency analysis and root-cause debugging in a distributed system. It is one of the three pillars of observability alongside metrics (aggregate health) and logs (detailed events), and the strongest answer ties them together: metrics tell you something is wrong, traces show you which service and which call, and logs (correlated by the same trace id) give you the detail. A practical caveat is sampling — tracing every request is expensive at scale, so systems sample a representative fraction.