What is distributed tracing and how does it work?

Distributed tracing is a technique for following a single request as it moves through multiple services in a distributed system. Without it, when a user reports slowness, you might see a problem in Service C but have no idea whether Service A or B caused it.

The mechanism works through context propagation. When a request enters the system, the first service generates a globally unique trace ID and a span ID for its own unit of work. Before calling a downstream service, it injects these IDs into the outgoing request headers — the W3C Trace Context standard (traceparent header) is the modern way to do this. The receiving service extracts those IDs, creates a child span linked to the parent span, and continues the chain.

Each span records: service name, operation name, start timestamp, duration, status, and any custom attributes (user ID, query string, etc.). The tracing backend — Jaeger, Zipkin, Tempo — collects all spans and stitches them into a tree called a trace. The waterfall view of that tree immediately shows which service added how much latency.

OpenTelemetry is now the de-facto standard for instrumentation: you add the OTel SDK to your service, configure an exporter (OTLP), and the spans flow to your backend of choice without vendor lock-in.