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.
3
What the interviewer is probing.
What the interviewer is probing.
4
1. "What problem does tracing solve that logs do not?" *Probing:* the value. *Stalls:* "More
detail." *Moves up:* one request across a dozen services — logs tell you each hop in isolation, a
trace shows the whole path and where the time went.
1. "What problem does tracing solve that logs do not?"
5
2. "What propagates the context?" *Probing:* the mechanism. *Stalls:* "A log id." *Moves up:*
trace and span ids passed in headers, now standardised as W3C traceparent, which every hop must
forward.
2. "What propagates the context?"
6
3. "What is sampling and why does it matter?" *Probing:* the practical angle. *Stalls:*
"Nothing." *Moves up:* storing every trace at volume is prohibitive, so you sample — ideally
tail-based so errors and slow requests are always kept.
3. "What is sampling and why does it matter?"
7
4. "What is the usual gap in a trace?" *Probing:* experience. *Stalls:* "None." *Moves up:* a
service that does not propagate headers, which breaks the chain and hides exactly the hop you are
chasing.
4. "What is the usual gap in a trace?"