The journey of a request: seven stops from socket to response
Every HTTP request makes the same trip — accept, parse, route, middleware, handle, serialize, drain. Knowing the map tells you where latency, failure, and security each hide.
A user clicks “Save”. 180 ms later they see a green checkmark. In those 180 ms the request crossed a load balancer, sat in a kernel queue, was parsed byte by byte, matched against a route table, walked a stack of middleware, ran your handler, was serialized to JSON, and streamed back out — passing through seven distinct stages, each with its own failure mode. Most engineers can name the handler. Few can name the other six.
The seven stops
Strip away the framework and every server-side request follows one shape. The names differ between Express, Spring, Go’s net/http, and Rails, but the stages do not:
Accept — the kernel completes the TCP handshake and hands your process a connected socket.
Parse — bytes off the socket are turned into a request line, headers, and a body.
Route — the method and path are matched to one handler.
Middleware — cross-cutting layers run in order: auth, logging, body parsing, rate limiting.
Handle — your business logic runs, usually waiting on a database or another service.
Serialize — the result becomes bytes: JSON, HTML, a stream.
Drain — the response is written to the socket, which may be slower than your handler, and the connection is kept alive or closed.
Together these seven stops form a chain: skip or misconfigure any one of them and you get a failure that looks mysterious until you know the map. The next ten minutes will make that map automatic.
Before stop 1, a reverse proxy (nginx, Envoy, a cloud load balancer) usually terminates TLS, picks a backend, and may buffer the whole request. That proxy is its own lifecycle — it has the same seven stops on the other side.
Where each problem hides
The reason the map matters is that each class of bug lives at a specific stop. Debugging blind means checking all seven; debugging with the map means going straight to one.
Symptom
The stop to suspect
Connections refused under load
Accept — the kernel accept queue overflowed
431 / 400 on large cookies
Parse — header buffer exceeded
Wrong handler runs
Route — overlapping path patterns
Auth bypass on one endpoint
Middleware — ordering: handler ran before the auth layer
p50 fast, p99 terrible
Handle — a slow downstream dependency
High CPU on big responses
Serialize — JSON.stringify on a huge object
Memory climbs with slow clients
Drain — backpressure ignored, response buffered in RAM
Latency is cumulative, not located
A request’s total time is the sum of every stop, plus the time it spends waiting in queues between them. A handler that runs in 5 ms can still produce a 200 ms response if the accept queue was deep, the body was buffered by the proxy, and the client read the response slowly. This is why “the code is fast” and “the endpoint is slow” are both true at once — they describe different stops.
The handler is a sliver of the response; latency is the sum across all seven stops plus queueing, which is why fast code can still feel slow.
The senior skill is not memorizing the seven names. It is forming the reflex: given this symptom, which stop? When you see a p99 spike or a connection flood, your first question should be “which stop is this?” — not “what does the code do?” The rest of this unit walks each stop in production detail.
Quiz
Completed
A service has a 3 ms handler but users report 250 ms responses under load. Which stops are the most likely culprits?
Heads-up The handler is one of seven stops. A fast handler does not make a fast response; queueing and draining happen outside it.
Heads-up Route matching is microseconds even with hundreds of routes. It almost never dominates a 250 ms response.
Heads-up Serializing a small response is sub-millisecond. Only very large objects make serialization visible.
Quiz
Completed
Why does a reverse proxy in front of your app server matter to the request lifecycle?
Heads-up The proxy has its own lifecycle. Your app still accepts, parses, routes, and so on — the proxy sits in front of all of it.
Heads-up A reverse proxy forwards requests; it does not run your handlers. Business logic stays in the app server.
Heads-up A proxy has no effect on how long your handler waits on a database — that is downstream of the proxy entirely.
Order the steps
Completed
Put the seven stops of a request in the order they happen:
1Accept — kernel hands the process a connected socket
2Parse — bytes become request line, headers, body
3Route — method + path matched to a handler
4Middleware — auth, logging, body parsing run in order
5Handle — business logic runs, waits on dependencies
6Serialize — result becomes bytes
7Drain — response written to socket, connection kept or closed
1. Acceptkernel queue overflow → refused
2. Parseoversized headers → 431/400
3. Routeoverlapping paths → wrong handler
4. Middlewarewrong order → auth bypass
5. Handleslow dependency → p99 spike
6. Serializebig object → CPU on the loop
7. Drainignored backpressure → memory
Every request makes the same seven stops in order; total latency is their sum plus queueing, and each bug class lives at exactly one stop.
Recall before you leave
01
Name the seven stops of the request lifecycle in order, and one thing that can go wrong at each.
02
Why can a service have a 3 ms handler but a 250 ms response time?
03
What does a reverse proxy add in front of the seven stops, and why does it have its own lifecycle?
Recap
Every server-side HTTP request follows the same seven stops: accept (kernel hands over the socket), parse (bytes become a request), route (path to handler), middleware (cross-cutting layers in order), handle (business logic), serialize (result to bytes), and drain (write to socket, keep-alive or close). A reverse proxy in front adds its own copy of this lifecycle. Total latency is the sum across stops plus queueing, which is why a fast handler can still yield a slow endpoint. Each class of bug lives at one specific stop — the value of the map is the reflex of jumping straight to the right one. Now when you see a service that is “slow but the code is fine,” your first move is to name the stop, not read the handler. The next lesson zooms into the first two stops: how the kernel accepts a connection and how raw bytes become a parsed request.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.