Backend Architecture
Async vs blocking: multiple-choice review
Crux Multiple-choice synthesis across the async/blocking unit — I/O models, the event-loop schedule, what blocks it, offloading CPU work, bounded concurrency, and tail latency under load.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make in a real incident — not a definition to recite, but a tradeoff to weigh while the loop is on fire and the tail is climbing.
Goal
Confirm you can connect the I/O model, the event-loop schedule, what freezes it, where CPU work belongs, how to bound fan-out, and why the tail explodes near saturation — the synthesis the six lessons built toward.
Quiz
Completed
Service A is a thread-per-connection app holding 50,000 mostly-idle keep-alive sockets; Service B is an event-loop app doing the same. Both are nearly idle on CPU. Why does A fall over while B stays comfortable?
Heads-up Idle blocking threads are parked by the OS, not spinning — A's CPU stays low. The cost is memory for stacks and scheduling overhead, not CPU spin.
Heads-up FD limits are a tunable per-process setting independent of the I/O model; both hit the same kernel limit. The real difference is per-connection thread cost.
Heads-up Per-read latency is essentially the same; epoll/kqueue only changes how you discover which sockets are ready, not how fast a single read completes.
Quiz
Completed
Inside an I/O callback you schedule setTimeout(a, 0), setImmediate(b), and Promise.resolve().then(c). What runs first, and what principle decides it?
Heads-up Source order never decides event-loop execution; the phase a callback belongs to and the microtask drain do. The promise reaction jumps ahead of both macrotasks.
Heads-up It is the reverse: microtasks are higher priority and are drained to empty after every callback, so the promise reaction runs before any timer or setImmediate.
Heads-up The loop is one thread; these callbacks are queued and ordered, never simultaneous. libuv threads run native I/O, not your JS callbacks.
Quiz
Completed
A two-line /health endpoint starts timing out, but only when a reporting route is hit. The reporting route runs JSON.parse on a 40 MB body. Why does health suffer, and what is the right diagnosis signal?
Heads-up Health touches no database and JSON.parse opens no connection — it is pure in-memory CPU. The monopolised resource is the loop thread, not a connection.
Heads-up There is no per-route OS scheduling here — it is one thread. And high CPU can be healthy; the truer signal is event-loop lag, the gap between when a callback was due and when the loop reached it.
Heads-up The libuv pool runs native I/O, never your JS request handlers, and the parse is JS on the loop. Enlarging the pool does nothing for a blocked loop.
Quiz
Completed
A CPU-heavy image resize (pure JS) freezes the loop. One engineer bumps UV_THREADPOOL_SIZE 4 to 32; another moves the resize into a worker thread. Who fixed it and why?
Heads-up The libuv pool never executes JavaScript, so it cannot run the resize regardless of size. Enlarging it only helps when you are bottlenecked on native fs/dns/crypto throughput.
Heads-up They are not equivalent — only the worker thread runs the JS off the loop. The pool change is a no-op for this bug and is the classic week-losing trap.
Heads-up Resizing is CPU-bound computation, which is exactly why it freezes the loop and why it must be offloaded to a worker (or chunked).
Quiz
Completed
A migration runs await Promise.all(millionIds.map(processUser)) and is OOM-killed before the first thousand finish, while the database refuses new connections. Root cause and fix?
Heads-up Promise.all behaves exactly as specified — it starts every promise immediately. The harm is the unbounded count of simultaneous operations, not a defect.
Heads-up The map callbacks do not block the loop; they are I/O-bound and yield. The problem is how many run concurrently, not that any single one blocks.
Heads-up More heap only delays the OOM and still floods the database past its connection limit. The durable fix is bounding concurrency to what the downstream can absorb.
Quiz
Completed
A Node service sits at 75% CPU with a 20 ms average; a small traffic spike pushes CPU to 82% and p99 jumps from 80 ms to 1,400 ms while the average barely moves. How do you read this?
Heads-up Nothing implies a leak; the nonlinear jump is the queueing curve near saturation, a property of load. The average reading 'fine' is exactly the trap.
Heads-up p99 is the meaningful signal here — it reveals the saturation the average conceals, and fan-out makes that 1-in-100 tail the typical experience of a multi-call page.
Heads-up One Node loop is one core's worth of JavaScript; extra cores need extra loops (cluster/instances). The deeper fix is running with headroom below the knee, not chasing the cliff with hardware.
Recap
The unit’s through-line is one chain of decisions: the I/O model sets how you spend the wait (park a thread vs multiplex on a loop), the loop’s phases and microtask drain set callback ordering, any synchronous span on the loop freezes every connection at once, CPU-bound JS belongs on a worker thread (not a bigger libuv pool) while long-but-splittable work can chunk, fan-out must be bounded to what the downstream absorbs, and near saturation queueing makes the tail explode — so you watch p99 and event-loop utilization, not the average, and run with headroom.