Cross-Cutting Concern Placement

## What the correlation-id hook is A **correlation id** is one opaque value that identifies a single inbound request for that request's whole lifetime. Every log line written while handling it, every metric sample it contributes to, and every call the service makes to another service carries the same value, so an operator holding one id can pull back everything that happened. The element that establishes it is an ordinary member of the framework's middleware chain: it runs on the way in, delegates to the rest of the chain, and does a little work on the way out. Concretely it does four things: 1. **Adopt or generate.** If the request carries a request-id header and the value passes a strict shape check, reuse it — that is what joins this service's records to the caller's. Otherwise generate a fresh value. 2. **Publish it.** Write the value into whatever per-request context the framework offers, so that a log call ten frames deep picks it up without anyone passing it as an argument. 3. **Propagate it.** Outbound calls made while handling the request send the same id on, so the next service adopts rather than invents one. 4. **Return it.** Put the id on the response, so a user quoting an error page or a client logging a failure hands you the exact search key. ## Why first, and not merely early The rule is mechanical: **a consumer cannot read state its producer has not yet written.** Every element of the chain that emits a record is a consumer — the access log, the metrics hook, the rate limiter when it rejects, the authentication hook when it fails, the error stage when it catches. If any of them is wrapped *outside* the correlation hook, its records are written before the id exists and are unjoinable forever. The requests where placement shows are the ones that never reach a handler: - a request refused by a body-size or content-type guard - a request answered `401` because its credential had expired - a request answered `429` by a limiter - a request that failed inside an inner hook and unwound to the error stage These are usually the most interesting requests during an incident, and they are precisely the ones a late-placed id hook drops. | Correlation hook placed | Records that carry the id | Records that do not | |---|---|---| | Outermost | access log, metrics, limiter rejections, auth failures, handler, error stage | none inside the chain | | After authentication | handler, error stage, anything the handler calls | access log for rejected requests, limiter rejections, auth failures | | Inside the handler | log lines the handler writes | everything the framework itself emits | ## Adopting an id from an untrusted caller An inbound id is caller-controlled input, and it flows into every log line and every outbound header — so it needs a cheap guard: a length cap and a restricted character set, with a generated id as the fallback. Two further points come up in interviews: - **An id is a join key, never an authorization token.** It must not grant access, address a resource, or be treated as unguessable. - **If you reject the caller's value, say so.** Recording the rejected value in a separate field keeps the join available to a human without letting unvalidated text become the primary id. ## Where the id has to live The id belongs in **per-request context** — state the framework scopes to one in-flight request — not in a process-wide variable and not on a long-lived shared object. A server handles many requests at once; anything shared between them will interleave, and the symptom is the worst kind: log lines attributed to the wrong request. Frameworks differ here, and it is worth saying so honestly in an interview: some carry per-request context across asynchronous boundaries automatically, so work handed to another pool keeps the id; others require the code doing the hand-off to capture the context explicitly, and forgetting is why an id present in the access log is missing from a background task's logs. ## What good placement looks like - Outermost of the application's own hooks — nothing meaningful sits outside it. - Cheap: no I/O, no lookups, no allocation worth worrying about. - Never short-circuits: it has no reason to reject anything. - Adopts rather than regenerates when an edge layer already minted an id. - Returns the id on **every** response, including failures. Get this one placement right and every other observability decision in the chain has something to hang on. Get it wrong and each of them degrades quietly, in a way that only shows up during the incident when you can least afford it.