Event Loop

// Timer phase: setTimeout/setInterval callbacks
setTimeout(() => console.log('timers phase'), 0);

// Check phase: setImmediate callbacks
setImmediate(() => console.log('check phase'));

// Microtasks: processed between ALL phases
process.nextTick(() => console.log('microtask - nextTick'));
Promise.resolve().then(() => console.log('microtask - promise'));

Why it matters: Understanding event loop phases is critical for predicting async execution order and debugging timing-related bugs. It's a common deep-dive question in senior Node.js interviews to distinguish surface-level from in-depth knowledge.

Real applications: Database connection pools in production apps leverage the poll phase — they register I/O listeners that wake the loop when query results arrive, enabling hundreds of concurrent DB operations without blocking.

Common mistakes: Assuming setTimeout(fn, 0) runs immediately after the current function — it doesn't. It waits for the timers phase in the next iteration, after all microtasks and the poll phase have completed.

setTimeout(() => console.log('1: timeout'), 0);
Promise.resolve().then(() => console.log('2: promise'));
process.nextTick(() => console.log('3: nextTick'));
// Output:
// 3: nextTick  (highest priority microtask)
// 2: promise   (microtask, after nextTick)
// 1: timeout   (macrotask, last)

Why it matters: Misunderstanding the microtask/macrotask queue order leads to subtle timing bugs that are extremely hard to reproduce. Senior developers are expected to predict execution order correctly in code reviews and debugging sessions.

Real applications: React's state batching and Vue's nextTick() use promise microtasks to batch DOM updates efficiently. Understanding this enables you to write framework-level scheduling logic correctly.

Common mistakes: Excessive microtasks can starve the macrotask queue — if promise chains keep resolving synchronously, timers and I/O callbacks may be delayed indefinitely, causing request timeouts and unresponsive servers.

console.log('start');
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');
// Output:
// start
// end
// promise   (microtask runs before timer)
// timeout

Why it matters: This is a standard interview question testing whether you truly understand async execution order. Many developers assume a 0ms delay means "now" — knowing it actually defers to the next loop iteration demonstrates solid event loop mastery.

Real applications: UI frameworks use setTimeout(fn, 0) to break up long tasks and allow rendering to occur between chunks, keeping applications responsive. It's also used to yield control back to the event loop in recursive operations.

Common mistakes: Relying on setTimeout(fn, 0) for precise timing — actual execution time depends on event loop load and preceding callbacks. For reliable post-I/O execution, prefer setImmediate() which guarantees running after the poll phase.

// BAD: blocks the event loop for ALL users
app.get('/heavy', (req, res) => {
  let sum = 0;
  for (let i = 0; i < 1e10; i++) sum += i; // blocks ~10 seconds
  res.send(`Sum: ${sum}`);
});

// GOOD: offload to worker thread
const { Worker } = require('worker_threads');
app.get('/heavy', (req, res) => {
  const worker = new Worker('./heavy-task.js');
  worker.on('message', result => res.send(`Sum: ${result}`));
});

Why it matters: This is a critical production concern — one blocked request in a Node.js server affects every other user. Interviewers test whether you can identify blocking code and know the correct remediation strategies.

Real applications: Image resize services and PDF generators must never run on the main thread. Companies like Cloudinary use separate worker processes or microservices to handle CPU-intensive media processing, keeping the API server loop free.

Common mistakes: Using synchronous methods like fs.readFileSync(), crypto.pbkdf2Sync(), or JSON.parse() on huge payloads inside request handlers — each blocks the entire server while processing one user's request.

console.log('A');
setTimeout(() => console.log('B'), 0);
Promise.resolve()
  .then(() => console.log('C'))
  .then(() => console.log('D'));
console.log('E');
// A → E → C → D → B
// C and D both run before B because microtasks drain fully

Why it matters: Understanding how promises interact with the event loop helps you write predictable async code and debug subtle ordering issues. It's tested in interviews to verify you can reason about async execution without running code.

Real applications: Database transaction managers use promise chains to sequence queries with predictable ordering — knowing that all .then() callbacks fire before any I/O callbacks ensures transaction steps execute in the correct order.

Common mistakes: Assuming a setTimeout inside a .then() callback will run before the next .then() — it won't. The entire promise chain resolves as microtasks before the timer fires, which can surprise developers expecting interleaved execution.

// Operations that USE libuv thread pool:
const fs = require('fs');
const crypto = require('crypto');
fs.readFile('data.txt', callback);           // file I/O
crypto.pbkdf2('pwd', 'salt', 1e5, 64, 'sha512', cb); // crypto

// Increase thread pool size (default: 4, max: 1024)
// UV_THREADPOOL_SIZE=8 node app.js
console.log(process.env.UV_THREADPOOL_SIZE); // '4'

Why it matters: libuv is the engine behind Node.js's non-blocking I/O. Knowing its thread pool helps you tune performance for I/O-heavy applications and understand why some "async" operations still consume threads.

Real applications: Applications doing heavy file processing or DNS lookups can improve throughput by setting UV_THREADPOOL_SIZE to match the number of concurrent I/O operations, prevent thread pool starvation.

Common mistakes: Assuming all async Node.js operations avoid threads — file system operations and dns.lookup() do use the thread pool. Exhausting the pool (e.g., 100 concurrent file reads with only 4 threads) creates a hidden performance bottleneck.

const fs = require('fs');

fs.readFile('file.txt', () => {
  // Inside I/O callback: setImmediate ALWAYS wins
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
  // Output: immediate → timeout
});

// Outside I/O: order is non-deterministic
setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

Why it matters: Choosing between setImmediate and setTimeout(fn, 0) has real ordering implications. Interviewers ask this to gauge your understanding of event loop phases and when each scheduling mechanism is appropriate.

Real applications: Recursive async processing patterns use setImmediate() to yield between iterations, allowing pending I/O events to be processed between batches — preventing the event loop from being monopolized by a single long-running task.

Common mistakes: Using setTimeout(fn, 0) instead of setImmediate() inside I/O callbacks expecting consistent ordering — setImmediate guarantees post-poll execution while setTimeout(fn, 0) may run in a different iteration entirely.

const { monitorEventLoopDelay } = require('perf_hooks');

const histogram = monitorEventLoopDelay({ resolution: 20 });
histogram.enable();

setTimeout(() => {
  console.log('Min lag:', histogram.min / 1e6, 'ms');
  console.log('Max lag:', histogram.max / 1e6, 'ms');
  console.log('Mean lag:', histogram.mean / 1e6, 'ms');
  histogram.disable();
}, 5000);

Why it matters: Event loop lag directly correlates with API response latency. Production teams set alerts on lag thresholds to detect CPU spikes or accidental blocking code before users experience timeouts.

Real applications: APM tools like Datadog, New Relic, and clinic.js continuously measure event loop lag and surface it in dashboards. Teams use lag spikes to pinpoint slow middleware, database calls, or CPU-intensive operations causing latency.

Common mistakes: Only monitoring request latency without tracking event loop lag — a slow third-party module or sync operation can spike lag without immediately affecting visible request times, masking an emerging performance problem.

// These operations USE the thread pool (block a thread):
const fs = require('node:fs');
const crypto = require('node:crypto');

fs.readFile('large.csv', callback);        // uses 1 thread
crypto.pbkdf2('pwd', 's', 1e5, 64, 'sha512', cb); // uses 1 thread

// These do NOT use the thread pool:
const https = require('node:https');
https.get('https://api.example.com', cb); // OS kernel handles it

Why it matters: Misunderstanding the thread pool leads to unexpected performance bottlenecks. Applications with heavy file I/O should tune UV_THREADPOOL_SIZE to prevent starvation when many concurrent operations are in flight.

Real applications: A file processing service reading 100 files concurrently with only 4 thread pool slots will have 96 requests queued. Setting UV_THREADPOOL_SIZE=16 dramatically reduces queue wait time and overall processing time.

Common mistakes: Assuming all Node.js async operations are "zero-thread" — file system operations consume thread pool slots. Also confusing dns.lookup() (thread pool) with dns.resolve() (OS network stack, no thread pool).

queueMicrotask(() => console.log('1: queueMicrotask'));
process.nextTick(() => console.log('2: nextTick'));
Promise.resolve().then(() => console.log('3: promise'));
// Output (priority order):
// 2: nextTick       (highest - processed first)
// 1: queueMicrotask (web standard - same queue as promise)
// 3: promise

Why it matters: Choosing the right microtask scheduler affects execution order in library code. Understanding the priority difference matters when building middleware, framework utilities, or libraries that depend on precise callback ordering.

Real applications: Node.js built-in EventEmitter uses process.nextTick() to defer event emissions, ensuring listeners can be attached before events fire. Library authors use it to guarantee "emit after current function returns" semantics.

Common mistakes: Using process.nextTick() when queueMicrotask() would work — creating Node.js-specific code that breaks in browser environments. Also recursively calling process.nextTick() which can starve promise microtasks.

const fs = require('fs');

// This callback is processed during the poll phase
fs.readFile('file.txt', (err, data) => {
  console.log('Poll phase: file read complete');

  // Runs in check phase (after current poll)
  setImmediate(() => console.log('Check phase: setImmediate'));

  // Runs in next timers phase (after poll + check)
  setTimeout(() => console.log('Timers phase: setTimeout'), 0);
});

Why it matters: Understanding the poll phase explains why Node.js doesn't spin at 100% CPU when idle — it efficiently blocks waiting for events using OS-level notifications, conserving resources until work arrives.

Real applications: HTTP servers spend most of their time in the poll phase, waiting for incoming connection events. When a request arrives, the poll phase wakes up, processes the socket event, and triggers request handlers.

Common mistakes: Confusing "blocking in poll" (efficient OS-level waiting, no CPU usage) with "blocking the event loop" (CPU-bound JS code running). The poll phase block is intentional and efficient — it's how Node.js avoids busy-waiting.

console.log('1: sync');

setTimeout(() => console.log('2: setTimeout'), 0);
setImmediate(() => console.log('3: setImmediate'));

Promise.resolve().then(() => console.log('4: promise'));
process.nextTick(() => console.log('5: nextTick'));

console.log('6: sync');
// Output: 1 → 6 → 5 → 4 → 2 or 3 (non-deterministic outside I/O)

Why it matters: Predicting async execution order is a litmus test in advanced Node.js interviews. Getting the order right shows you understand the complete call stack, microtask queue, and event loop phases rather than guessing.

Real applications: Framework internals like Express middleware and database ODMs depend on correct async ordering to chain operations. Understanding order prevents race conditions when combining promises, callbacks, and event emitters.

Common mistakes: Assuming async/await makes everything run synchronously — it still uses the microtask queue. An await suspension point yields to the event loop, and subsequent code after await runs as a promise microtask callback.

// BAD: starves all I/O and timers indefinitely
function dangerousRecursion() {
  process.nextTick(dangerousRecursion);
}

// GOOD: yields to event loop between iterations
function safeRecursion(items) {
  if (items.length === 0) return;
  processItem(items[0]);
  setImmediate(() => safeRecursion(items.slice(1)));
}

// GOOD: same principle with async generators
async function* processStream(items) {
  for (const item of items) {
    yield processItem(item);
    await new Promise(r => setImmediate(r)); // yield to loop
  }
}

Why it matters: This is a critical production concern — a single module using recursive process.nextTick() can make an entire Node.js application completely unresponsive. Identifying and fixing this pattern is essential for production stability.

Real applications: Stream processors and batch job runners that iterate over large datasets use setImmediate() to yield between chunks, allowing incoming HTTP requests to be handled between batch iterations.

Common mistakes: Using async/await in a tight loop without yielding — if each awaited operation resolves synchronously (e.g., reading from a local cache), the loop may run as continuous microtasks, starving I/O just like recursive process.nextTick().

const { Worker, isMainThread, parentPort } = require('worker_threads');

if (isMainThread) {
  const worker = new Worker(__filename);
  worker.on('message', result => console.log('Result:', result));
  worker.postMessage({ task: 'compute', data: 1_000_000 });
} else {
  parentPort.on('message', ({ data }) => {
    // Heavy computation runs in worker's own event loop
    let sum = 0;
    for (let i = 0; i < data; i++) sum += i;
    parentPort.postMessage(sum);
  });
}

Why it matters: Worker Threads are the modern solution for CPU-bound work in Node.js. Understanding their relationship with the main event loop is critical for designing high-performance systems that handle both I/O and computation.

Real applications: Video transcoding APIs, ML inference endpoints, and cryptographic operations use Worker Threads to process requests in parallel without blocking the main server loop that handles routing and I/O.

Common mistakes: Creating a new Worker for every request — worker creation is expensive. Production systems maintain a worker pool (using poolifier or similar) and reuse workers across multiple tasks to amortize startup costs.