Baggage in Distributed Tracing
Baggage is key-value context propagated alongside a trace across service boundaries, so downstream services can read values set upstream. It enables cross-cutting context like tenant id, but it travels in headers on every hop, so overuse adds latency and leak…
Why it exists
Sometimes a downstream service needs a piece of context that was only known at the very edge of the system, like which customer tier made the request or which A/B variant is active. Passing it explicitly through every function signature and API call is invasive. Baggage exists to carry that context implicitly along the trace.
The mental model
Think of baggage as a small envelope of key-value pairs that rides along with the request everywhere it goes. You drop a value in at one service, and any later service in the call chain can open the envelope and read it, without the intervening services having to know or forward it manually. It is distinct from span attributes, which are local to one span and do not travel.
How it works
When a service makes a downstream call, the tracing library serializes baggage into propagation headers, in OpenTelemetry a dedicated baggage header, alongside the trace context. The receiving service deserializes it back into its context, and the cycle repeats on each hop. Because it is part of context propagation, it flows automatically wherever trace context flows, including across process and network boundaries.
When it matters
Baggage matters when several services need shared request-scoped context for routing, sampling decisions, or enriching their own telemetry, for example tagging every span downstream with the originating tenant. It matters in the other direction too: because every key-value pair is copied into headers on every hop, you must keep baggage small and never put secrets or PII in it, since it spreads to all participating services including third parties.
A concrete example
An API gateway sets baggage tenant id equal to a customer identifier. Ten services later, a database access layer reads that baggage value to choose the right shard and to tag its own spans, even though none of the intermediate services touched or forwarded the value explicitly. If someone naively added a full auth token to baggage, it would now be exposed on every downstream hop, illustrating the leak risk.
Interview question
How does baggage differ from a span attribute, and what risk follows from that difference?
- a.Baggage stays on one span; the risk is it is too local to be useful
- b.Baggage is identical to a span attribute with no added risk
- c.Baggage is stored only in metrics; the risk is high storage cost
- d.Baggage propagates across all downstream services; the risk is leaking sensitive data on every hopCorrect
Why? this is the answer
Baggage rides in propagation headers to every downstream service, unlike span attributes which stay local. That cross-service spread means sensitive values placed in baggage leak to all hops, including third parties.
Just read this? Test yourself on what you have been reading.
- #baggage
- #distributed-tracing
- #opentelemetry
- #context-propagation
- #observability
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles