Where in a middleware chain do access logging and request metrics belong, and what does placing them too deep hide?

## What these hooks are for An **access log** writes one record per request describing what happened: method, route, status, duration, size, and the correlation id. A **request metric** is the aggregate form of the same event: a counter of requests and a latency distribution, labelled with at least route and status. Both are *observers* — they change nothing about the request, and their only requirement is coverage. Coverage is a placement property. A middleware element can only observe what it wraps, so an observer's depth in the chain decides, exactly, which requests it can see and how much of each request's life it can measure. ## Why outermost Put them at the outer edge (just inside the correlation-id hook) and three things follow: - **Every request produces a record.** Including the ones no handler ever saw. - **The duration is the request's duration.** The timer starts before any inner hook and stops after the response has been produced, so it includes body buffering, credential verification, limiter lookups and serialization. - **The status is the status actually sent.** Because an outer observer's after phase runs once the response has been settled by everything inside it, including the error stage. ## What a too-deep observer hides Move the observers inside authentication and rate limiting, and the records they emit describe a service that is healthier and quieter than the real one: - rejections are invisible — a credential-stuffing wave answered `401`, or a client being throttled all afternoon, shows up as *less traffic*, not as a problem; - latency is understated, because the most expensive part of a slow request is often the part before the handler (a large body, a slow credential lookup); - error rates look flat, because failures raised by outer hooks never pass through the counter; - a traffic drop becomes ambiguous: you cannot tell whether clients stopped calling or the chain started refusing them. | Observer placed | Requests counted | Duration measured | |---|---|---| | Outermost (inside correlation id) | all, including every rejection | whole chain, in and out | | Inside auth and rate limiting | only those that got past both | chain minus the outer hooks | | Inside the handler | only those that reached the handler | handler body only | ## The tension: route labels A metric labelled by **raw path** is a well-known way to destroy a metrics backend: every identifier in a URL becomes its own time series, and a scanner probing random paths invents thousands more. The label must be the **route template** — the matched pattern, not the concrete path. But an outermost hook runs *before* routing, so on the way in it does not know the template. This pulls naive implementations inward, which trades away the coverage that justified the placement in the first place. The resolution is to keep the hook outermost and split its work across phases: 1. On the way in: start the timer, nothing else. 2. Delegate. 3. On the way out: read the matched route that routing recorded on the request context, read the final status, and emit. When nothing matched, or the request never reached routing, emit a single constant label — one series for all unmatched traffic — rather than the path. That keeps cardinality bounded while still counting the request. ## Practical rules that come out of this - **One access-log line per request, written in the after phase**, not one on the way in and one on the way out; a line written on the way in cannot carry status or duration. - **Keep the observers cheap and non-failing.** An observer that throws turns a served request into an error; if the log destination is unavailable, drop the record, do not drop the request. - **Do not put anything that can reject a request outside them.** Whatever sits outside the access log is, by construction, unlogged. - **Label sparingly.** Route, method, status class. Anything caller-controlled is a cardinality risk. - **Metrics and logs at the same depth.** If the two observers sit at different depths, their totals will disagree during exactly the incident where you need them to agree. ## How to answer this in an interview Say the principle first — *an observer must wrap what it observes* — then name the categories of request that a deep observer loses, then show that you know the route-label tension and resolve it with the after phase rather than by moving the hook. That sequence demonstrates you have reasoned about the chain rather than copied a known-good ordering.