The Invisible Thread

A request crosses a boundary. The next service must continue the story.
But how does it know where the story began?

gateway

→

api

distributed trace trace

gateway

320ms

api

270ms

trace_id: 4bf92f3577b58681a65c3c24e8d2d7ac

Both spans share the same trace_id. The trace appears connected. But gateway and api are separate processes, separate machines. How does api know it belongs to the same trace?

What carries trace context between services?

↓

HTTP header

HTTP request from gateway to api

traceparent: 00-4bf92f3577b58681a65c3c24e8d2d7ac-00f067aa0ba902b7-01

When gateway calls api, it sends a traceparent HTTP header. This single header carries everything api needs to continue the same trace.

Four segments, separated by dashes:

00 = version (always 00 today) 4bf92f...d7ac = trace-id (32 hex chars — the shared identity) 00f067...02b7 = parent-span-id (16 hex chars — the calling span) 01 = trace-flags (01 = sampled)

Now match each segment to its meaning

00 - 4bf92f3577b58681a65c3c24e8d2d7ac - 00f067aa0ba902b7 - 01

→

trace-id

4bf92f...d7ac

→

trace-flags (sampled)

00f067...02b7

→

version

→

parent-span-id

The traceparent header is the invisible thread. It carries just enough — a trace ID, a span ID, and a flag — for every service to continue the same story.

This is the W3C Trace Context standard. No vendor lock-in. One header. Universal propagation.

Continue →