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 (or the W3C traceparent header) 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.
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, propagate W3C traceparent alongside it, and include the ID in the job payload for anything queued. 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.