Describe the inject/extract carrier model OpenTelemetry uses to move context across a process boundary, and how you would apply it to a transport that is not HTTP, such as a message broker's record headers.

## The abstraction Cross-process propagation needs two orthogonal decisions: the wire *format* of the context, and the *place* it is written. OpenTelemetry keeps them separate. A `TextMapPropagator` owns the format. It has three operations: ``` inject(context, carrier, setter) # serialise current context into the carrier extract(context, carrier, getter) -> context # parse a carrier into a new context fields() -> [names it writes] # so callers can clear stale values ``` The carrier is whatever object holds the key/value pairs — a header map, a metadata object, a list of record headers. The setter and getter are small adapters supplied by the instrumentation: ``` setter.set(carrier, key, value) getter.get(carrier, key) -> value or null getter.keys(carrier) -> all keys ``` That is the whole contract. It is why the same W3C propagator works unchanged over HTTP, gRPC, and a broker: only the four-line adapter differs. `fields()` is easy to overlook and matters in practice: when you reuse a message or request object, you should clear the propagator's fields before injecting, otherwise a stale `traceparent` from a previous use can survive and parent the new operation to the wrong span. ## Composite propagators A composite (or multi) propagator wraps several propagators. On inject it writes all of their formats; on extract it tries each in order and takes the first valid result. Two standard uses: combining trace context with baggage (almost always what you want), and interoperating during a migration — accept both W3C and B3 while some services still emit only the old format, and emit both until every consumer understands the new one. The cost is header bytes on every request, so it is a migration state, not a destination. ## Getter and setter details that bite - **Case-insensitivity.** HTTP header names are case-insensitive; a getter over a plain case-sensitive map will miss `TraceParent` sent by a non-conforming client. Getters over HTTP carriers must fold case. - **Multiple values.** Headers can repeat. Trace context requires a single `traceparent`; the spec says a duplicated header makes the context invalid, so a getter that silently returns the first value can produce a context the sender never intended. - **Binary carriers.** Broker headers are often byte arrays rather than strings; the adapter must decode with a fixed charset (UTF-8) on both sides. - **Immutable carriers.** Some client libraries expose request objects that are already frozen at the point instrumentation runs, which is why injection has to happen at the right lifecycle stage rather than wherever it is convenient. ## Applying it to a message broker Producing: 1. Start a producer span while the current context is the one that caused the send. 2. Inject the context into the message's *headers*, using a setter that appends to the record's header list. Headers, not the payload body: injecting into the body changes the message schema, forces every consumer to understand tracing, and defeats brokers or bridges that only forward headers. 3. Send. Do this at produce time, not at flush or batch-completion time — by then the ambient context is a different request's. Consuming: 1. For each message, extract a context from its headers with the same propagator. 2. If the consumer handles one message per unit of work, use the extracted context as the parent: the trace continues naturally across the queue. 3. If the consumer processes a *batch*, the messages usually come from many different traces. Forcing one parent would be a lie. The convention is to start one processing span whose parent is the local consumer context, and attach each message's extracted span context as a **link** — a typed reference that says "related to, but not a child of". Backends render links as navigable cross-trace edges. Span kinds should be `PRODUCER` and `CONSUMER` rather than client/server, which is what lets a backend show the asynchronous edge correctly. ## Consequences of propagating through a queue A trace that crosses a queue can span minutes or hours: the producer span ends immediately, the consumer span begins when the message is picked up. Some backends assemble such traces poorly, or have already flushed and indexed the earlier part. Deep retry chains and dead-letter requeues can also extend one trace id indefinitely, or fan a single trace into thousands of spans. Two mitigations: prefer links over parenting when the asynchronous gap is large or the fan-in is wide, and consider starting a fresh trace with a link back to the origin when a message is replayed from a dead-letter queue much later. ## Interview summary Say that the propagator owns the format and the setter/getter pair owns the carrier, which is why the model is transport-agnostic; then walk the produce/consume path, call out headers-not-body, and explain links for batch consumption.