← Lessons

quiz vs the machine

Gold1410

System Design

Trace Context Propagation

How the trace id rides along with every call so spans across services join up.

5 min read · core · beat Gold to climb

The stitching problem

Each service creates its own spans, but they only form one trace if every service knows the shared trace id and its parent span id. Context propagation is how that identity travels from caller to callee.

How it travels

When a service makes an outbound call, it injects the trace context into the request, typically as HTTP headers. The receiving service extracts those headers, continues the same trace, and starts a child span. A widely used standard is the trace context header format, which carries the trace id, the parent span id, and sampling flags.

  • Inject on the way out, writing context into headers or message metadata.
  • Extract on the way in, reading context and creating a child span.
  • For queues and async work, the context rides in message attributes instead of headers.

Why it breaks

  • A service that does not forward the headers breaks the chain, splitting one trace into two.
  • Thread or callback boundaries can lose the in process context if not carried carefully.
  • Third party hops that strip unknown headers drop the context.

Auto instrumentation libraries handle inject and extract so most code does not deal with headers directly.

Key idea

Context propagation injects the trace id into outbound calls and extracts it on arrival, so spans across services stitch into one continuous trace.

Check yourself

Answer to earn rating on the learn ladder.

1. How does trace context usually travel between services over HTTP?

2. What happens if one service fails to forward the trace context?

3. How is context carried for asynchronous queue based work?