What the correlationId buys you
One stable id flows through API ingress, MDC, NATS payloads, webhook headers, and audit rows. The downstream join cost approaches zero.
A correlationId is the cheapest piece of infrastructure with the highest payoff in a distributed system. RateStack mints one at API ingress (or honors an inbound X-Correlation-Id) and propagates it through every span, log line, NATS event payload, webhook delivery header, and audit row.
Why this matters operationally
Customer reports an issue. The error response carries the correlationId (every RFC 7807 error includes it). One log query returns the entire timeline: API ingress, every internal call, the NATS events emitted, the webhook deliveries fired, the audit rows written. No string matching across timestamps. No fuzzy joins.
Why this matters for downstream consumers
Hedge desks, BI stacks, and bid-tape reconcilers consume RateStack events. Every event carries the correlationId. Joining pricing.computed with locks.created with sell-side completions becomes a deterministic join on a single column.
Compare to systems that don't propagate a stable id: you join on (timestamp ± window) and (loanId, investorId, programId), hope the windows are right, and accept some join error rate. The correlationId eliminates the entire class of fuzzy-match problems.
How to do it right
Mint at the boundary. Honor inbound when present (with sanity check). Put it in MDC immediately. Include it in every error response and every event payload. Propagate via header on every internal call. Resist the urge to use multiple ids for "different concerns" — one id is the point.