Carrying a request ID end to end: edge, logs, downstream calls and the response

Goal

Make one request findable across every log the system writes, from the reverse proxy to the last downstream service, using a single identifier that also appears in the response the user received.

Prerequisites

A reverse proxy or gateway in front of the application, structured logging with a per-record field set, and a way to hold request-scoped state in the application (thread-local, contextvars.ContextVar in Python, a context object in Go).

Steps

1. Generate the identifier at the outermost component you control. nginx provides $request_id, documented as a unique identifier generated from 16 random bytes in hexadecimal; write it to the access log and pass it upstream with proxy_set_header X-Request-ID $request_id;.
2. In the application, read the header on entry. Accept a supplied value only after validating its length and character set; otherwise generate one. Store it in request-scoped context. In Python a ContextVar set at the start of the request is visible to code and to asynchronous tasks created from that context, so no function needs an extra parameter.
3. Add the identifier to every log record through the logging library's filter or processor, as a fixed field name (request_id) that all services share.
4. Forward it on every outbound HTTP call, into message headers for queued work, and into the job record for background tasks, so the consumer restores it before logging.
5. Return it in the response as X-Request-ID and print it on error pages and in API error bodies, so a user or support agent can quote it.
6. If tracing is in use, use the W3C traceparent trace ID (32 hex characters) as the request identifier instead of inventing a second one; then logs, traces and the response share one key.
7. Test with one request: take the ID from the response and confirm that the proxy log, each service's log and the queue consumer's log all contain it.

Expected result

Given an ID from a bug report, a single search returns the ordered log lines of that request across all components, and a missing component is immediately visible as a gap.

Limits and test basis

The identifier is for correlation only: it is not a session token, must not be used for authorisation, and a client-supplied value is untrusted input. Requests that fan out into many downstream calls share one ID; the per-call ordering comes from timestamps or from spans. Retries reuse the ID by design, which makes duplicated work visible.