What is distributed tracing in microservices?

WHAT THIS TESTS 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.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.