What is distributed tracing in microservices?
observability across service boundaries.
a trace is a tree of spans tied by trace and span IDs, propagated via headers like W3C traceparent.
confusing tracing with plain logging or metrics.
What's really being asked
The interviewer wants to know if you understand why request-scoped visibility matters once a single user action fans out across dozens of services, and whether you grasp the mechanics of stitching those calls together.
The full answer
Distributed tracing records the path of a single request as it travels through services. Each unit of work is a span with a start time, duration, and metadata; spans link into a tree via a shared trace ID and parent-child span IDs. In microservices this matters because a slow or failing request can touch ten services and logs alone cannot tell you where time went or where the error originated. Context propagation is the key mechanism: the caller injects identifiers into outbound request headers, commonly the W3C traceparent header or the older B3 set, and the callee extracts them to continue the same trace. Mention OpenTelemetry as the vendor-neutral standard for instrumentation and export to backends like Jaeger or Tempo.
The mistakes people make
Describing tracing as just centralized logging, conflating it with metrics, or claiming it works automatically without any instrumentation or header propagation. Forgetting that async boundaries like message queues need explicit context carrying.
What usually comes next
How does sampling reduce overhead? What is the difference between a span and a log line? How do you propagate context across a Kafka message or a thread pool?
A concrete example
A checkout request hits the API gateway, which generates trace ID abc and span 1. It calls the cart service over HTTP with header traceparent containing abc and span 1 as parent; cart creates span 2, then calls inventory, producing span 3. In Jaeger you see one waterfall showing inventory took 800ms, immediately pinpointing the bottleneck without grepping logs across three services.
Interview question
A request fails somewhere across five services. What does distributed tracing give you that aggregated logs alone do not?
- a.A guaranteed reduction in total request latency
- b.The causal, timed parent-child path of that single request across all servicesCorrect
- c.A real-time alert whenever any service exceeds its error budget
- d.Automatic root-cause remediation without human intervention
Why? this is the answer
Tracing ties spans into one timed tree via propagated trace and span IDs, showing where the request went and how long each hop took. Alerting on error budgets is a metrics/SLO concern, not what a trace provides.
Just read this? Test yourself on what you have been reading.
Read the original → opentelemetry.io
- #observability
- #tracing
- #microservices
- #opentelemetry
- #spans
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on observability — each one lists the topics its interview covers.
See open roles