Node.js interview questions: The event loop and async I/O

The waiting happens in the kernel, and that's the piece most people miss. When a connection comes in, libuv registers the socket's file descriptor with whatever readiness mechanism the platform has - epoll on Linux, kqueue on macOS, IOCP on Windows. Then the loop parks itself in its poll phase, sleeping inside a single syscall, till the kernel reports that some descriptor has activity. An idle connection costs you one file descriptor, some kernel socket-buffer memory, and a little bit of JS heap state. No thread, no stack. So ten thousand idle sockets are basically free, because epoll_wait scales with how many sockets have events, and idle sockets have none.

There's a second, smaller mechanism for operations which have no readiness model. Regular files always report ready, but the actual read can still block on the disk, so that work goes to libuv's thread pool - four threads by default. The fs module runs there, dns.lookup also runs there, and the async crypto functions pbkdf2, scrypt and randomBytes too. But dns.resolve* doesn't - that one goes through c-ares on non-blocking sockets. And createHash and createCipheriv simply run synchronously on whatever thread called them.

So the full picture is one V8 thread running every callback, the kernel watching your sockets, and four pool threads soaking up the file and DNS work. Once you keep this split in your head, you can start predicting things. Ten thousand concurrent HTTP requests hitting a handler that queries Postgres is fine, because that is all socket work. But ten thousand concurrent fs.readFile calls - four will run and the rest will queue. The async API looks identical in both cases, and the scaling is completely different.

Once this is running in production, what I actually care about is what stalls that one shared thread, and what tells me about it first. Any synchronous work in a handler will do it. A multi-megabyte JSON.parse, a backtracking regex, a tight loop over some big array. Every other connection's callbacks wait behind it. The symptom is p99 climbing on every endpoint at once while host CPU looks moderate, because one core is pegged and the rest are sitting idle. The tool I reach for is perf_hooks.monitorEventLoopDelay, a native histogram sampled at 10ms resolution by default. Export the p99 and the max, never the mean. And pair it with performance.eventLoopUtilization, because ELU near 1.0 with low lag means a steady stream of small callbacks is saturating the thread without any single visible stall.

The other thing that saturates is the pool. I've seen this exact incident - an auth service doing pbkdf2 on every login fills all four threads, then dns.lookup, which shares the same pool, starts queueing behind it, so outbound HTTP from the same process becomes slow and nobody connects it back to logins. Bumping UV_THREADPOOL_SIZE buys some headroom. The durable fixes are moving password hashing into worker threads using the *Sync variants (because pbkdf2Sync blocks only the worker's own thread, while async crypto called from a worker lands right back on the same process-wide pool), and getting dns.lookup out of hot paths with keep-alive agents or dns.resolve.

For capacity, it's one process per core with cluster or container replicas, connection count bounded by fd limits and per-socket memory, and throughput bounded by per-request CPU on the loop thread. Do this math before you pick the platform. 5ms of CPU per request caps a process near 200 req/s, no matter how asynchronous the I/O is. Fan-out I/O workloads fit this architecture. CPU-per-request workloads don't.

I keep two structures in my head for this, because Node schedules from both of them. The first one is a pair of drain-to-empty queues - Node's own nextTick queue, and V8's microtask queue, which is where promise reactions and queueMicrotask callbacks land. After any callback returns (and the main script itself counts as a callback here), Node drains the whole nextTick queue, then the whole microtask queue, and only after that the loop gets to advance. This drain happens after every single callback. Between every timer, between every I/O event.

The second structure is the phases, which always run in one fixed order - timers, pending callbacks, poll, check, close. setTimeout entries fire in the timers phase once the loop's clock crosses their due time, and setImmediate fires in check. And here's the trap - Node clamps a timeout of 0 up to 1ms, and this clamp is what creates the main-script race. If the process takes more than a millisecond to reach the first timers phase (module loading or a first GC will easily do it), the timer is already due and it fires before check. On a fast start, the loop is there in under a millisecond and the immediate wins. Same binary, but different output from one run to the next.

Inside an I/O callback, the ambiguity just disappears. You're sitting in the poll phase, and check comes next, before the loop ever gets back to timers. So setImmediate wins there every single time.

And that gives you the answer to the puzzle. Sync code, then nextTick, then the promise callback, always in this order. Then either the timeout or the immediate, if the pair came from the main script. And if you queued that pair inside an I/O callback, then the immediate always comes first.

Three real-world things hang off this ordering. The first one is API contracts. Library code leans on nextTick to guarantee that events emit after the caller has finished attaching listeners. A constructor that emits synchronously loses events, and one that emits on a timer adds latency and reorders against other callbacks. Streams and a big chunk of core rely on this, which is why nextTick is still around despite its starvation risk. So when you're writing an emitter or a callback API, the place where you defer is part of the contract, because callers can observe whether their own synchronous code ran before your callback fired.

The second is test stability. Any assertion that depends on the main-script timeout-versus-immediate race will pass or fail based on startup timing, and it fails more under CI load, because slower startup pushes the 1ms clamp past the first timers phase. I've watched teams just keep hitting retry on those. The fix is structural - don't assert cross-phase ordering that you don't control, use fake timers for time-based logic, and when a test needs to run after all pending I/O, chain setImmediate instead of setTimeout(0).

The third is throughput. The 1ms clamp turns every setTimeout(0) hop into paid dead time, so a chunked batch job built on it spends most of its wall clock inside the timer machinery itself. setImmediate yields through the poll phase with no clamp at all. I've seen that one substitution take a migration script from hours down to minutes.

And when the ordering surprises you, just measure it. A ten-line script with timestamped logs will settle what some blog post from 2016 can't, and advice from the node --stack-size era ages badly. The queues are observable, so go and look at them directly.