Backend Architecture
Request lifecycle: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before opening the model answer — the effort of reconstructing the mechanism is what makes it stick.
Reconstruct the unit’s spine without looking back: the seven stops, the two kernel queues, why middleware order is a security boundary, the backpressure mechanism, keep-alive, and how timeouts must compose into a budget.
- 01Name the seven stops of the request lifecycle in order, and one failure that lives at each.
- 02What are the two kernel queues behind a listen() socket, what bounds each, and why is somaxconn = 128 a production trap?
- 03Why is middleware registration order a security boundary, and what is the ordering rule?
- 04Trace exactly how a slow client causes server-side OOM during a streamed response, layer by layer.
- 05What does serialization cost the request, and why does the status code function as a contract rather than decoration?
- 06What does keep-alive optimize, and why must per-hop timeouts compose into a propagated deadline?
If you could reconstruct each answer from memory, you hold the unit’s spine: seven stops whose latencies sum plus queueing; two kernel queues where somaxconn silently caps the accept depth; middleware order as a security boundary; backpressure as the userland surface of TCP flow control that OOMs when ignored; serialization as real synchronous CPU and the status code as a contract; and timeouts that must compose into a propagated deadline because the fan-out tail, not the average, sets user-perceived latency.