Correlation ID
One ID attached to a single request and stamped on every log it produces, so you can pull that request's whole story out of the pile.
See it
What it is
A correlation ID is one identifier minted at the edge of your system and stamped onto every log line, span, and error that request produces, including the ones from services further down the chain. Without it, logs from concurrent users are shuffled together like a dropped deck of cards. With it, one search returns the complete story of a single request in order.
The pattern: middleware reads an incoming X-Request-Id and generates a UUID if there isn't one, stashes it in request-scoped storage such as Node's AsyncLocalStorage, binds it to a child logger, forwards it on every outbound call, and echoes it back in the response headers and on your error page. That last part is the sleeper feature: a user pastes 'error ref 9f2c' into a support ticket and you are one query from the answer.
W3C traceparent is a different animal and not a drop-in substitute. It is a structured header carrying a version, a trace ID, a parent span ID, and flags, so the whole value is not an identifier you copy around: let your tracing SDK parse and propagate it, then, if you want logs and traces to line up, pull the trace ID out of the parsed context and log that as its own field. Keep the request ID as a separate field alongside it, because the two answer different questions and one can exist without the other.
Gotcha: IDs die at async boundaries. Push work onto a queue, fire a webhook, or spawn a background job and the context is gone unless you carry the ID in the job payload yourself. The other classic is minting a fresh ID per service instead of propagating the original, which gives every hop its own unrelated ID and quietly defeats the whole point.
Ask AI for it
Add correlation IDs to this app. In HTTP middleware, read x-request-id from the incoming request or generate a UUID v4 if absent, store it in AsyncLocalStorage, and bind it to a child logger so every log line in that request carries request_id automatically. Forward the header on all outbound fetch and service calls, and include the ID in the job payload for anything queued. Handle W3C traceparent separately: let the tracing SDK parse and propagate it rather than treating the raw header value as an ID, and log the extracted trace ID as its own trace_id field next to request_id. Echo the ID back in the response headers, attach it as a tag on captured exceptions, and show it on the user-facing error page as an error reference.