What is distributed tracing and how do correlation IDs work?

Question

Accepted Answer

**Distributed tracing** follows a single request as it travels across many services, so you can see the end-to-end path and find where latency or errors occur. A **correlation/trace ID** ties all the spans of one request together.

## How it works

The first service generates a **trace ID**; every downstream call propagates it (and a parent **span ID**) in headers.

```http
GET /checkout HTTP/1.1
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
# trace-id ───────────────────────────^   ^── span-id
```

```text
Trace abc123:
  Gateway      ├──────────────────────────────┤ 220ms
   Orders        ├────────────┤ 90ms
    Payments        ├──────┤ 60ms   ← slow span found here
    Inventory       ├──┤ 15ms
```

## What it gives you

- **Latency breakdown** — which service/span is slow.
- **Error localization** — which hop failed.
- **Dependency map** — what actually calls what.

Tools: OpenTelemetry (instrumentation), Jaeger / Zipkin (storage + UI).

## Pitfalls

```text
⚠️ If one service drops the trace header, the trace breaks
⚠️ 100% sampling is expensive — sample, but keep errors
⚠️ Logs are useless across services without the correlation ID attached
```

## Why it matters

Without tracing, debugging a slow or failing request across a dozen services is guesswork; with it, you see exactly which hop is to blame.

Propagating a correlation ID through every log line and call is the single highest-leverage observability investment in a microservices system.