Backend Architecture
Putting it together: multiple-choice review
Crux Cross-track synthesis MCQs for the backend capstone: composition over addition, the latency cascade, nested timeout budgets, goodput vs throughput, the p99 tail, and readiness as a checklist.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole backend track at once. None tests a single mechanism in isolation — each puts two or three of them on the same request, under the same load, and asks you to read the interaction the way you would in a real incident.
Goal
Confirm you can reason about the seven mechanisms as one composed system: how a correct part becomes another part’s bad input, how the timeout budget threads the stack, why goodput beats throughput, and why readiness is verified, not felt.
Quiz
Completed
Every one of the seven backend mechanisms passes its own tests, yet the team's worst incidents come from places no single mechanism explains. What is the capstone's diagnosis?
Heads-up Each mechanism can be individually correct and the system still fail. The point is that the bug lives in the seams between mechanisms, not inside any one — there is no broken part to find.
Heads-up The gap is composition of the existing mechanisms, not a missing one. The unit adds observability and load control as connective tissue that ties the seven together, not a new isolated concern.
Heads-up Production-ready is an emergent property of the system that cannot be verified by inspecting parts; passing parts do not sum to a correct whole because each mechanism changes the environment the others run in.
Quiz
Completed
A payment provider's p99 climbs from 40ms to 4s — no errors, just slow answers. Minutes later endpoints that never call the provider are also slow. Which mechanism's correct behaviour propagated the fault, and through what?
Heads-up The database is healthy. The coupling is the shared pool and event loop, not a dependency between provider and database — a fault spreads through shared resources, not through the downstreams themselves.
Heads-up The breaker tripping sheds the provider calls and frees connections; it relieves the cascade rather than causing the generalization. The pool draining on held connections is what spreads the slowness first.
Heads-up They need not touch the provider at all. They slow because they compete for the same exhausted pool — which is precisely how a single-dependency fault becomes everyone's problem.
Quiz
Completed
A POST /payments handler has a 3-second total budget set in middleware, but the downstream provider call, the pool acquire, and the DB write each carry their own 3-second timeout. Why is this wrong even though every individual timeout looks reasonable?
Heads-up Giving every inner layer the full budget lets any one of them consume it alone, making the failure later, less diagnosable, and resource-draining. Budgets are nested, not independent.
Heads-up Idempotency makes a retry safe; it does nothing about a hung call holding a pooled connection for the full budget. That is a timeout-nesting problem, not a correctness-of-retry problem.
Heads-up That makes every request potentially 9s slow and still lets a hung step starve the pool for that long. The fix is smaller, nested inner deadlines so the innermost slow thing fails first and frees its resources in time.
Quiz
Completed
During a cascade the slow provider fully recovers — latency back to 40ms — but the service stays collapsed. What does this reveal, and what is the right response?
Heads-up Even with a genuinely recovered provider the system stays collapsed, because the queue and retries it created now feed the loop themselves. That self-sustaining loop is the definition of metastability.
Heads-up Waiting does not help a metastable state; the loop is self-sustaining. You need active intervention — shed load, drain queues, cut retries — not patience.
Heads-up One restart does not drain a fleet-wide queue or stop clients retrying. Metastable failures need load shedding and retry control across the system, not a single bounce.
Quiz
Completed
A service is past saturation — demand exceeds capacity — and currently accepts and queues every request. Why does adding fast 503-with-Retry-After shedding at the edge increase the number of users served well?
Heads-up Rejected requests do not vanish from the world — clients may retry — but shedding them cheaply at the door protects capacity for the requests you accept. The win is goodput, not lower demand.
Heads-up The mechanism is queue control, not error speed. Not accepting excess work keeps queues short so in-capacity requests finish in time; cheap rejection merely enables that.
Heads-up Capacity is fixed by the hardware and downstreams. Shedding does not raise C; it stops you wasting C on work beyond it, preserving goodput within the fixed capacity.
Quiz
Completed
A readiness review on a complex new payment service comes back 'all eight gates fully green, no caveats.' Why is a senior reviewer more skeptical than reassured?
Heads-up Services do launch safely. The skepticism is not that safety is impossible but that a complex new service with zero caveats signals undocumented tradeoffs rather than genuine completeness.
Heads-up There is no fixed verdict color. The point is honest calibration to blast radius with explicit caveats, not blanket pessimism.
Heads-up The number of gates is not the issue; honest depth per gate proportional to the cost of failure is, with tradeoffs made explicit rather than papered over.
Recap
The through-line across the track is one claim: composition is not addition. A correct pool draining under a slow downstream becomes the breaker’s bad input; a correct retry becomes a storm; a correct drain races a stuck in-flight job. The timeout budget must nest down the stack so the innermost slow thing fails first; under overload you protect goodput by shedding the excess on purpose; you can only operate what you can see at the p99 tail, not the mean; and readiness is a checklist calibrated to blast radius, not a feeling. Senior backend work is reading the interaction graph before it cascades.