Backend Architecture
Request lifecycle: multiple-choice review
Crux Multiple-choice synthesis across the request lifecycle — accept queues, middleware order as a security boundary, serialization cost, backpressure, and tail amplification under fan-out.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across all seven stops. Each one mirrors a real incident — not a stage to name, but a symptom to localize to one stop and the mechanism that explains it.
Goal
Confirm you can take a symptom and jump to the right stop: connect accept-queue limits, middleware ordering, serialization cost, backpressure, and tail amplification into one decision reflex.
Quiz
Completed
Under a traffic burst, clients get connection timeouts and resets, but the application logs are completely empty — no 500s, no handler traces. Which stop, and why are the logs empty?
Heads-up An exception runs inside your code, so it appears in the logs and usually returns a 500. Empty logs mean the request never reached the application at all — the drop is upstream, in the kernel accept queue.
Heads-up Serialization happens long after accept(), on requests that did reach your code. If connections are refused before any handler runs, serialization is irrelevant and there would still be logs for requests that got through.
Heads-up Ignored backpressure OOMs on responses being actively written — that produces a crash with heap-growth symptoms, not silent connection refusals with empty logs during the burst.
Quiz
Completed
A security review finds one admin endpoint serves unauthenticated requests, even though the auth middleware is implemented, tested, and registered. What is the most likely cause?
Heads-up Reaching the correct admin handler means routing worked. The failure is that nothing authenticated the request before the handler ran — an ordering bug, not a matching bug.
Heads-up A parse/format problem would reject valid users (deny access), not grant access to unauthenticated ones. Allowing everyone through points to auth never executing, which is an ordering issue.
Heads-up Routing is microseconds regardless of route count, and a timeout would not silently skip auth — it would fail the request. The handler simply ran ahead of the auth layer in registration order.
Quiz
Completed
An endpoint is 40% slower after its result set grew from 50 to 5,000 rows, yet the database query time is unchanged at 8 ms. Where did the time go, and what is the first fix?
Heads-up Route matching cost is independent of response size (and is microseconds anyway). Result-set size affects producing the response, not finding the handler.
Heads-up The accept queue bounds pending connections, not response size. It refuses connections under load; it does not make a successful response slower in proportion to its row count.
Heads-up Keep-alive affects connection-setup cost, which does not scale with the number of rows in one response. A 40% slowdown tracking payload size points at serialization.
Quiz
Completed
A streaming export OOMs only when a client downloads over a slow link. The code calls res.write() in a loop and ignores the return value. What is the precise mechanism?
Heads-up false does not mean failure — the data was accepted into the buffer. It is a backpressure signal meaning 'slow down', not 'retry'. The growth is unread data buffered in userland, not duplicated writes.
Heads-up GC runs normally; it simply cannot reclaim buffers still referenced by the pending write queue. The bytes are live data the consumer has not read, not garbage.
Heads-up Retransmits are normal and bounded by the TCP stack; they do not cause unbounded heap growth. The growth is application-level: production rate decoupled from the client's read rate.
Quiz
Completed
A product page fans out to 100 independent services in parallel and waits for all. Each has a p99 of 10 ms (1% chance a call exceeds it). Roughly what fraction of page loads exceed 10 ms on at least one call, and what is the durable fix?
Heads-up 1% is the per-call rate. With 100 independent calls and a wait-for-all join, the chance that none is slow is 0.99^100, so the slow fraction compounds to ≈63%. Independence does not protect you when you wait for all.
Heads-up Tail amplification is not linear. The compounding 1 − (1 − p)^N grows far faster than a linear estimate; at p=1%, N=100 it is ≈63%, not 10%.
Heads-up You are slow if any one is slow, not only if all are. Waiting for all means a single slow dependency among 100 sets the whole page's latency — which is exactly what amplifies the tail.
Quiz
Completed
A request has a 1 s SLA. Service A (client timeout 1 s) calls service B (client timeout 1 s). When B hangs, A keeps working for the full second after the client has already given up. Why, and what fixes it?
Heads-up Length is not the root issue — composition is. Even well-chosen local values sum past the SLA without a shared, propagated budget; the fix is a deadline, not a smaller constant.
Heads-up Clients do support timeouts — both A and B set 1 s here. The flaw is that isolated timeouts do not roll up into one deadline carried down the call chain.
Heads-up Application timeouts are honored. The failure is architectural: no remaining-budget deadline is propagated, so inner hops outlive the caller's patience.
Recap
The through-line of the unit is one reflex: given a symptom, jump to the stop that owns it. Empty logs under a burst means the accept queue (somaxconn) dropped connections before any code ran; an unauthenticated endpoint means middleware order, not auth logic; a slowdown that tracks payload size means serialization; an OOM under slow clients means ignored backpressure; and a slow page despite healthy services means tail amplification under fan-out, fixed with propagated deadlines and hedging. Latency is the sum across all seven stops plus queueing — so the map turns blind debugging into a single jump.