Node.js Event Loop and Async Interview Questions

The event loop is libuv's loop that runs ready callbacks on the main thread. Each turn has six phases, each with its own queue:

1. timers: due setTimeout and setInterval callbacks
2. pending callbacks: some deferred system I/O callbacks
3. idle, prepare: internal
4. poll: wait for and run I/O callbacks
5. check: setImmediate callbacks
6. close callbacks: 'close' events

After every callback (timers and setImmediate too, since Node 11), Node drains process.nextTick, then promise microtasks. See the event loop.

Sync code runs first, then microtasks in queueing order: queueMicrotask was called before .then. The loop reaches the timers phase only when the microtask queue is empty, even for a 0 ms timer.

process.nextTick runs right after the current operation, before promise callbacks (in CommonJS; see the ES module question). setImmediate runs in the check phase, after I/O polling. setTimeout(fn, 0) runs in the timers phase after at least 1 ms.

// Node.js, CommonJS file
setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));
Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));
console.log('sync');

Node prints sync, nextTick, promise, then timeout and immediate in either order. The names are backwards: nextTick is the immediate one, and a recursive nextTick can starve I/O.

From the main module it is not guaranteed: it depends on whether 1 ms has passed when the loop reaches the timers phase. Inside an I/O callback setImmediate always runs first, because check comes right after poll.

const fs = require('node:fs');

fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
});
// Node.js always prints:
// immediate
// timeout

setImmediate is a Node.js API, not a web standard, so this order is a Node.js rule; see setImmediate vs setTimeout.

Because an ES module's top-level code runs inside a promise job. When a CommonJS file ends, Node drains nextTick first, then microtasks. An ES module body ends while microtasks are already draining, so its promise callbacks run first.

process.nextTick(() => console.log('nextTick'));
Promise.resolve().then(() => console.log('promise'));
console.log('sync');

The process.nextTick docs show both orders. Never depend on this order; make it explicit with await.

Everything waits: timers fire late, requests queue up, health checks time out.

const start = Date.now();

setTimeout(() => {
  const waited = Date.now() - start;
  console.log('asked for 10 ms, waited at least 200:', waited >= 200);
}, 10);

// 200 ms of synchronous work, like a huge JSON.parse or a sync crypto call
while (Date.now() - start < 200) {}
console.log('busy loop done');

Common causes: JSON.parse on huge payloads, sync fs or crypto in a handler, a regex with catastrophic backtracking. Measure with perf_hooks.monitorEventLoopDelay(); fix by chunking with setImmediate or a worker thread.

A pool of threads (4 by default) that libuv uses for work the OS cannot do asynchronously. Your JavaScript never runs there.

The trap: with 4 threads, 8 concurrent pbkdf2 calls take about twice as long as 4. Raise it with the UV_THREADPOOL_SIZE environment variable before Node starts (maximum 1024).

A waiting connection costs almost nothing: Node registers each socket with the OS (epoll, kqueue, IOCP) and runs code only when data arrives, where a thread-per-request server parks a thread per client. The limit is CPU per request: at 5 ms of JavaScript each, one process tops out near 200 requests per second.

forEach ignores the promises its callback returns, so right after the loop nothing is done, and the sleeps finish in time order. Use await Promise.all(items.map(...)) (parallel) or for...of with await (one at a time). See async and await.

Use util.promisify for any function with an error-first callback, or the promise APIs Node ships: fs/promises, timers/promises, stream/promises.

const util = require('node:util');

function legacyDouble(x, callback) {
  setTimeout(() => {
    if (x < 0) return callback(new Error('negative input'));
    callback(null, x * 2);
  }, 1);
}

const double = util.promisify(legacyDouble);

async function main() {
  console.log(await double(21));
  try {
    await double(-1);
  } catch (err) {
    console.log('caught:', err.message);
  }
}
main();

They differ in when they settle:

const ok = (ms, value) => new Promise((resolve) => setTimeout(() => resolve(value), ms));
const fail = (ms, msg) => new Promise((_, reject) => setTimeout(() => reject(new Error(msg)), ms));

async function main() {
  try {
    await Promise.all([ok(20, 'a'), fail(10, 'b failed'), ok(30, 'c')]);
  } catch (err) {
    console.log('all:', err.message);
  }
  const settled = await Promise.allSettled([ok(20, 'a'), fail(10, 'b failed')]);
  console.log('allSettled:', settled.map((r) => r.status).join(', '));
  console.log('race:', await Promise.race([ok(20, 'slow'), ok(5, 'fast')]));
  console.log('any:', await Promise.any([fail(5, 'x'), ok(20, 'first success')]));
}
main();

When Promise.all rejects, the other operations keep running; nothing is cancelled.