Before learning the solution, it helps to feel the pain that makes it necessary.

One user click, many services

When a customer presses the “Place Order” button in a shopping app, the request rarely stays inside one program. It may visit an API gateway, then an order service, then an inventory service, a payment service, and a notification service. Each of these is a separate process, often running on a different machine, written in a different language, and owned by a different team.

Each service can create its own spans, which are timed records of work. But if each service creates them in isolation, you end up with five small, unrelated traces instead of one story. The engineer looking at the tracing tool sees fragments and cannot answer the most basic question: “which of these pieces belong to the same customer request?”

Why services cannot just share memory

Inside one program, passing information around is easy because functions can share variables. Across services, no such sharing exists. Two services only talk by sending messages over a network, such as HTTP requests or queue messages. Any information that must travel from one service to the next has to be written into that message by the sender and read from it by the receiver.

This is exactly what injection and extraction do. They are the writing step and the reading step of carrying tracing identity across process boundaries.

A few basic words need to be clear before we go deeper.

Why parent links need the parent’s identity

To create a child span in the payment service, that service must know the span ID of the span in the order service that made the call. Without it, the new span would have no parent and would start a brand new trace with a brand new trace ID. The whole purpose of propagation is to deliver the parent’s trace ID and span ID to the child, even though the child lives in a different process.

The word “context” is used in many places in programming, so let us pin down exactly what it means here.

The context object

In OpenTelemetry, a context is a small, immutable container that holds values relevant to the current piece of work. Immutable means that it cannot be changed once created. When you want to add something, you create a new context that contains the old values plus the new one. This design keeps things safe when many threads or tasks run at the same time.

The most important value stored in the context is the currently active span, which in turn gives access to the trace ID, the span ID, and the sampling decision. The context can also hold baggage, which is a set of user-defined key-value pairs that you want to travel along with the request.

Where the current context lives

Inside one process, the SDK keeps track of the “current” context for you, using whatever mechanism suits the language, such as thread-local storage or an async-aware storage mechanism. When your code starts a span, the span is made current, and any code running afterwards can discover which span it belongs to without being handed any extra parameters.

Two kinds of context travel

It is useful to separate two journeys. The first is the journey inside one process, where the SDK manages the current context for you. The second is the journey between processes, where the context must be turned into text, sent over the wire, and rebuilt. Injection and extraction deal only with the second journey.

Propagation is the big idea. The carrier is the vehicle that does the carrying.

What propagation means

Context propagation means moving context from one place to another so that related work can be linked together. It happens in two directions across a service boundary. On the sending side, the context is serialized, which means converted into a plain text form. On the receiving side, that text is parsed back into a context object.

What a carrier is

A carrier is the thing that physically transports the serialized context. It is whatever message structure the two services already use to talk to each other. For an HTTP call the carrier is the set of request headers. For a message queue the carrier might be the message headers or properties. For a remote procedure call the carrier is the call metadata.

The carrier is not owned by OpenTelemetry. It belongs to the protocol in use. OpenTelemetry simply borrows a little room in it, usually a few header fields, to hold the context text.

Injection happens on the sending side, right before the request leaves the service.

What injection does

Injection takes the current context, finds the active span inside it, converts its identity into text according to a chosen format, and writes that text into the carrier. After injection, the outgoing message carries the trace ID, the span ID of the caller, and the sampling decision, plus any baggage that the application attached.

When injection happens

Injection happens at the exact moment the client is about to send the message, and while the client span for that call is active. This timing matters. The span ID written into the message should be the ID of the client span representing the outgoing call, because that span will become the parent of the work done on the other side.

Extraction is the mirror image of injection and happens on the receiving side.

What extraction does

Extraction takes an incoming message, looks into its carrier for the propagation fields, parses their text back into structured values, and builds a context object that represents the caller’s identity. The result is a context that says “the work I am about to do was caused by that span, in that trace.”

Remote parent: a special idea

The span context rebuilt by extraction is marked as remote. This flag tells the system that the parent span lives in a different process and that this service did not create it. It is a small detail with big value, because samplers and tools use the flag to treat incoming parents differently from local ones.

What happens next

The extracted context is then used as the parent when the server creates its own span. That server span receives the same trace ID as the caller and records the caller’s span ID as its parent. At this instant, the two services are stitched into one trace.

OpenTelemetry offers a clean, small interface that hides the differences between carriers.

The propagator

A propagator is the component that knows one specific wire format. It has exactly two jobs, matching our two halves of the story. One job is to inject a context into a carrier. The other job is to extract a context from a carrier. Because the interface is so small, you can swap one format for another without changing the instrumented code.

Why setters and getters exist

Carriers come in many shapes. An HTTP header collection behaves differently from a message properties map or a metadata object. To avoid writing a separate propagator for every combination, OpenTelemetry splits the work. The propagator decides what text to write and which names to use. The setter and getter decide how to actually put text into, or read text from, a particular carrier type.

Global propagator and configuration

Instrumentation libraries do not choose a format themselves. They ask the SDK for the globally configured propagator and use that. This is why a single configuration setting can change the format used by every instrumented library in your application. The usual configuration is a standard environment variable named OTEL_PROPAGATORS, which holds a comma-separated list of format names. The common default combines W3C Trace Context and W3C Baggage.

flowchart LR
    CTX["Current context"] --> P1["Propagator inject"]
    P1 --> S["Setter writes fields"]
    S --> CAR["Carrier, for example headers"]
    CAR --> G["Getter reads fields"]
    G --> P2["Propagator extract"]
    P2 --> NCTX["New context on receiver"]
        

The standard that most modern systems use to write trace identity on the wire.

Why a standard matters

Before a common standard existed, every tracing tool invented its own header names and layouts. A service using one tool could not pass identity to a service using another. The W3C Trace Context specification solved this by defining a single, vendor-neutral format. It is the default choice in OpenTelemetry today, which is why traces can flow smoothly across products from different vendors.

The traceparent header

The core of the standard is a single header called traceparent. It holds four pieces of information separated by dashes, all written as lowercase hexadecimal text.

The sampled flag

The trace flags part carries one especially important bit, the sampled flag. It tells the receiver whether the trace is being recorded. This lets all services in the chain make the same decision, so you do not get traces with missing middle sections. We will come back to this when we discuss sampling.

Validation rules

The specification forbids an all-zero trace ID or an all-zero parent ID. A header that breaks the layout rules is treated as invalid, and a receiver must not use it. This protects systems from malformed or damaged values.

Trace identity is not the only thing that can travel. Two other fields often ride along.

Tracestate: vendor notes

The tracestate header is a companion to traceparent. It holds a list of key-value pairs that tracing vendors can use to carry their own extra information, without breaking the shared standard. For example, a vendor might store a sampling priority or a routing hint. Other systems are expected to pass the field along unchanged, even if they do not understand it, and to respect size limits on the list.

Baggage: your own data

Baggage is a different and more flexible feature. It lets your application attach its own key-value pairs to the context so that they travel to every downstream service. Typical examples are a customer tier, a feature flag name, or a region code. Any service in the chain can read the values and use them to enrich its own telemetry or change its behavior.

Baggage travels in its own header, separate from traceparent. It is handled by its own propagator, which is why the default configuration lists both Trace Context and Baggage side by side.

Real systems are rarely uniform. Older tools and special platforms use other formats, and OpenTelemetry can speak several at once.

Other well-known formats

Composite propagators

A composite propagator is a wrapper that holds several propagators and runs them together. On injection, it writes all the formats at once, so that recipients using any of them can understand the message. On extraction, it tries each format in the configured order, and the first one that finds valid identity wins.

This is the practical tool for migration. Suppose half of your services still speak B3, and the other half have moved to W3C Trace Context. By configuring both formats everywhere, traces flow across the whole fleet during the transition, and you can retire the old format later.

flowchart TD
    OUT["Outgoing message"] --> COMP["Composite propagator"]
    COMP --> W["W3C Trace Context writes traceparent"]
    COMP --> B["Baggage writes baggage"]
    COMP --> L["Legacy format writes older headers"]
    W --> MSG["Message with all headers"]
    B --> MSG
    L --> MSG
        

Let us follow one customer request and watch injection and extraction work together.

The scenario

A customer places an order. The request arrives at an order service, which calls a payment service, which in turn calls a fraud-check service. All three services use OpenTelemetry with the default propagators.

sequenceDiagram
    participant C as Customer App
    participant O as Order Service
    participant P as Payment Service
    participant F as Fraud Service
    C->>O: Request without trace identity
    Note over O: No identity found, start new trace and root span
    Note over O: Create client span, inject identity
    O->>P: Request with traceparent
    Note over P: Extract identity, create child server span
    Note over P: Create client span, inject identity
    P->>F: Request with traceparent
    Note over F: Extract identity, create child server span
    F-->>P: Response
    P-->>O: Response
    O-->>C: Response
        

Reading the story

Synchronous calls are the easy case. Real systems also use queues, schedulers, and background workers.

Messaging systems

With a message queue, the sender and receiver are not connected at the same moment. The sender puts a message on the queue and moves on, and the receiver picks it up later, maybe seconds or hours later. The context must therefore be stored inside the message itself, in its headers or properties, so that it survives the wait.

On the sending side, injection writes identity into the message properties before publishing. On the receiving side, extraction reads those properties when a consumer takes the message. The consumer span can then be linked back to the producer span.

Parent-child versus links

Asynchronous workflows raise a design question. Should the consumer’s work be a child of the producer’s span, or should it only be loosely linked? For a single message processed soon after sending, a parent-child relationship is natural. For batches, where one consumer processes many messages at once, a single parent is impossible, so the consumer span records links to the span contexts of every message in the batch.

In-process async boundaries

Even inside one process, work can hop between threads or tasks. Thread pools, timers, and callbacks may run code on a different thread than the one that holds the current context. If the context is not carried along, the spans created in the new thread will not find their parent. Instrumentation libraries usually wrap these mechanisms, but custom thread handling may need you to capture the context and attach it again manually.

Browsers and mobile apps

Frontend applications can also start traces and inject headers into calls to the backend. For browsers there is an extra rule: cross-origin calls only allow headers that the backend explicitly permits, so the backend must allow the trace header names, or the browser will refuse to send them.

Injection and extraction do more than link spans. They also carry the decision about whether to record the trace at all.

What sampling is

Recording every trace in a busy system is expensive. Sampling is the practice of keeping only a portion of traces. A sampler is the component that decides, at the start of a trace, whether to record it.

How the decision travels

When the first service decides to sample a trace, it sets the sampled flag in the trace flags. Injection copies that flag into the outgoing message. On extraction, the downstream service reads the flag and, with a common parent-based sampler, follows the same decision. This keeps all spans of a trace together, either all recorded or all dropped.

flowchart LR
    A["Service A decides to sample"] --> B["Injects sampled flag"]
    B --> C["Service B extracts flag"]
    C --> D{"Parent sampled?"}
    D -- "Yes" --> E["Record spans in B"]
    D -- "No" --> F["Do not record spans in B"]
    E --> G["Inject same flag onward"]
    F --> G
        

Why consistency matters

If each service made its own random decision, a trace might be recorded in service A, dropped in service B, and recorded again in service C. The tracing backend would show a tree with a missing middle. By passing the decision through the context, every service stays in agreement.

Anything that crosses a boundary can be read, forged, or leaked. Context propagation is no exception.

Untrusted incoming context

Headers from the public internet can be set by anyone. A malicious client could send a forged traceparent with a chosen trace ID and a sampled flag turned on. If your service blindly trusts it, an attacker could force you to record huge numbers of traces, filling storage, or could try to pollute your traces with misleading identifiers.

To reduce this risk, many organizations ignore or replace incoming trace context at the public edge, such as at an API gateway, while trusting it on internal calls. Some also limit sampling decisions that come from outside.

Leaking data to third parties

Injection writes context into every outgoing call that instrumentation covers, including calls to third-party services outside your control. Trace identifiers are not usually secret, but baggage can contain business data. If a customer tier or internal identifier is placed in baggage, it may be sent to an external vendor that you called.

Size and abuse

Baggage and tracestate have size limits for good reason. Large values can bloat every request, slow down networks, or even cause servers to reject calls. Strict limits on both the number of entries and the total length help keep systems healthy.

When a trace looks broken, the cause is almost always found at a boundary between two services.

How to recognize broken propagation

Habits that work

Traps to avoid

Short answers to questions that come up again and again.

Usually not. Instrumentation libraries for common web frameworks, HTTP clients, database drivers, and messaging systems perform injection and extraction automatically. You write manual code mainly for custom protocols or unusual carriers.

No. Distributed tracing is the broader practice of recording and viewing requests across services. Context propagation is the mechanism that makes it possible, because it links the spans from different services into one trace.

No. Injection and extraction are done inside applications by SDKs and instrumentation. The collector receives already-finished telemetry, and it uses the trace IDs inside the data, but it does not forward request context between your services.

If it is only a pass-through, such as a simple proxy that forwards headers unchanged, the trace can continue on the other side. If it drops the headers, the trace breaks there. The service will not appear in the trace, because it creates no spans.

The header carries the ID of the caller’s span, which becomes the parent. The server then creates its own new span with its own new ID, and records the received ID as its parent. Every span has a unique ID, and the header always points to the previous one.

Yes. A composite propagator combines several formats. On injection, all formats are written. On extraction, they are tried in order. This is the standard way to support both old and new formats during a migration.

No. Baggage travels with the request but does not become a span attribute by itself. You must read it and add it as an attribute yourself, or use a component designed to copy selected baggage entries onto spans.

The propagator treats it as if no context were present and does not raise an error. The server span then starts a new trace. For this reason, silent failures should be caught by testing, not by waiting for errors.

It is a good habit. Once context is extracted, the current span’s trace ID and span ID are available to logging libraries, which can add them to each log line. This lets you jump from a log entry to its trace.

The cost is very small. It involves writing and reading a few short text fields. The more noticeable cost, if any, comes from large baggage values, so keep those compact.

Modern applications are built from many small services, and each service sees only its own slice of a request. Context injection and extraction are the two small actions that stitch those slices into a whole. Injection copies the identity of the current span into an outgoing message, and extraction reads that identity from an incoming message and uses it as the parent of new work. Propagators define the format, getters and setters adapt to each carrier, and standards such as W3C Trace Context keep different systems speaking the same language. When this works, one trace ID follows a request from the edge to the deepest dependency. When it fails, it usually fails quietly at a boundary, so thoughtful configuration, testing, and security habits are what keep your traces whole.