As a platform owner, what governance and failure-mode concerns would you set for Baggage propagation across a large service fleet?

**Why baggage needs governance.** Unlike a header you set on one call, baggage is **transitively propagated**: once in scope it rides on *every* downstream request and message for the whole trace, and (if correlated) is written into the **MDC/logs** of every service. That reach makes it excellent for correlation and hazardous for security, cost, and reliability. A platform owner treats baggage as a shared, blast-radius-wide resource. **1) Allow-list & ownership.** Because Spring only propagates fields declared in `management.tracing.baggage.remote-fields` (and correlates those in `correlation.fields`), configuration *is* the control point. Ship a **shared config baseline** (a starter/BOM or config server defaults) defining the approved set — e.g. `tenantId`, `requestId`, `experimentCohort` — each with a documented owner and purpose. Teams can't silently add fields that then spread fleet-wide. Review additions like you'd review a new public API. **2) Security — treat baggage as public.** - **No secrets** (tokens, keys) and **no PII** you wouldn't broadcast: baggage flows to every internal service, is copied into logs (a wide exfiltration surface), and may reach third-party tracing backends. - **Strip at trust boundaries.** Inbound baggage from untrusted callers can be **spoofed** (a client could set `tenantId` to another tenant) — never trust inbound baggage for authorization; derive authz from authenticated identity, not baggage. Strip or overwrite internal baggage at the edge, and strip it again on egress to external partners so internal context doesn't leak. - **Injection/log-forging.** Values reach the MDC; sanitize to avoid log-injection (newlines/control chars) and don't let user-controlled baggage pollute log parsing. **3) Reliability — silent failure modes.** - **Format & naming drift.** Mismatched propagation format (W3C vs B3) or inconsistent field **names/casing** across services causes *silent* context/baggage loss — no error, just broken correlation. Standardize both fleet-wide (prefer **W3C**). - **Context loss in async code.** Raw threads, un-instrumented executors, reactive boundaries, and manual message handling drop baggage/trace context. Mandate context-propagating executors / Reactor context propagation / `ContextSnapshot`, and test it. - **Scope leaks.** `BaggageInScope` must be closed (try-with-resources) or values bleed across requests on pooled threads. **4) Cost & performance.** Each remote field is extra bytes on **every** hop's headers and **every** message header. On high-QPS HTTP and high-volume topics this adds real bandwidth and can hit **header-size limits** (proxies/brokers reject oversized headers). Keep the field count small and values short; be especially conservative on messaging fan-out. Correlated fields also raise log volume and can add **high-cardinality** dimensions if you index them. **5) Observability of the mechanism itself.** Monitor for: traces that split (propagation broken), consumers starting as roots (missing extraction), and unexpected baggage fields appearing (drift). Consider synthetic checks that assert a known baggage field survives end-to-end. **When baggage is the right tool.** A *few* stable, non-sensitive correlation keys that many services need to log/branch on. It is **not** a substitute for passing request data explicitly, a config channel, or an authz mechanism. **Summary posture.** Small approved allow-list; public, non-sensitive values only; standardized format + names; stripped at edges; overhead-budgeted; and continuously monitored for silent breakage.