Backend Architecture

The journey of a request: seven stops from socket to response

Crux 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.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at junior altitude — the surface

◷ 10 min

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.

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 senior skill is not memorizing the seven names. It is forming the reflex: given this symptom, which stop? The rest of this unit walks each stop in production detail.

Quiz

A service has a 3 ms handler but users report 250 ms responses under load. Which stops are the most likely culprits?

Quiz

Why does a reverse proxy in front of your app server matter to the request lifecycle?

Order the steps

Put the seven stops of a request in the order they happen:

1 Accept — kernel hands the process a connected socket
2 Parse — bytes become request line, headers, body
3 Route — method + path matched to a handler
4 Middleware — auth, logging, body parsing run in order
5 Handle — business logic runs, waits on dependencies
6 Serialize — result becomes bytes
7 Drain — response written to socket, connection kept or closed

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. The next lesson zooms into the first two stops: how the kernel accepts a connection and how raw bytes become a parsed request.

Connected lessons

unlocks

Accept and parse: from kernel queue to a typed requestmiddle

deepens into

Accept and parse: from kernel queue to a typed requestmiddle

appears again in185

Continue the climb ↑Accept and parse: from kernel queue to a typed request