Event Loop & Non-blocking IO

console.log('1: Starting');
fs.readFile('file.txt', () => console.log('3: File read complete'));
console.log('2: This runs before the file read finishes');
// Output order: 1, 2, 3 -- the file read happens in the background
// while the main thread continues executing other code

Common follow-ups: What specifically happens to a request if a piece of synchronous, CPU-heavy code runs during the event loop's processing?;How does the event loop relate to and differ from multi-threading in a language like Java?

setTimeout(() => console.log('timers phase'), 0);
setImmediate(() => console.log('check phase'));

fs.readFile(__filename, () => {
  setTimeout(() => console.log('timer from within poll'), 0);
  setImmediate(() => console.log('immediate from within poll')); // guaranteed to run first here
});

Common follow-ups: Why is the ordering between setTimeout(fn, 0) and setImmediate() considered non-deterministic at the top level of a script but deterministic inside an I/O callback?;What specifically happens during the poll phase when there's no pending I/O and no timers scheduled?

// Blocking: freezes the entire event loop until the file is fully read
const data = fs.readFileSync('large-file.txt');

// Non-blocking: the event loop remains free to handle other work meanwhile
fs.readFile('large-file.txt', (err, data) => {
  console.log('File read complete');
});

Common follow-ups: In what specific, narrow scenario is a synchronous function like readFileSync() actually the correct choice?;How does non-blocking I/O in Node.js compare conceptually to how a traditional multi-threaded server achieves concurrency?

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

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

setInterval(() => {
  console.log('Mean lag (ms):', histogram.mean / 1e6);
  histogram.reset();
}, 10000);

Common follow-ups: How does event loop lag differ from and relate to overall CPU usage as a health metric?;What threshold of event loop lag typically indicates a genuine problem requiring intervention?

function processLargeArray(items, index = 0) {
  const chunkEnd = Math.min(index + 1000, items.length);
  for (let i = index; i < chunkEnd; i++) { /* process items[i] */ }
  if (chunkEnd < items.length) {
    setImmediate(() => processLargeArray(items, chunkEnd)); // yields to I/O between chunks
  }
}

Common follow-ups: Why can recursive use of process.nextTick() starve I/O entirely, while recursive setImmediate() doesn't have the same effect?;In what scenario would you deliberately choose process.nextTick() over a regular Promise microtask for similar 'run soon' semantics?

// If there's truly nothing else for the event loop to do,
// it blocks efficiently in the poll phase rather than spinning the CPU
setTimeout(() => {
  console.log('This fires after the specified delay, not immediately,\n' +
  'because the loop was blocked efficiently in poll with nothing else to process');
}, 5000);

Common follow-ups: How does this efficient blocking behavior in poll relate to why Node.js processes typically show very low idle CPU usage?;What happens to the poll phase's behavior specifically when there are active immediate callbacks waiting?

// This blocks the event loop entirely until the loop completes
for (let i = 0; i < 100000000; i++) {
  result += computeExpensiveValue(i);
}
// No other request can be handled by this process during this entire loop

Common follow-ups: How would you refactor this large synchronous loop to avoid blocking the event loop, using either chunking or a worker thread?;Does running multiple cluster workers actually solve this specific problem, or does it just limit its blast radius to one worker?

// I/O-bound: Node.js's model shines here -- handles many concurrently with one thread
app.get('/user/:id', async (req, res) => res.json(await db.users.findById(req.params.id)));

// CPU-bound: blocks everything else on the main thread if done directly
app.get('/process-image', (req, res) => res.json(applyComplexImageFilter(req.body.image))); // problematic

Common follow-ups: What are some example workloads where a different runtime or language might actually be a better default fit than Node.js?;How does offloading CPU-bound work to worker threads reconcile Node.js's single-threaded model with genuinely needing to use multiple cores?

// The exact same fs.readFile() call works identically across every OS,
// even though the underlying OS mechanism libuv uses differs completely
fs.readFile('file.txt', (err, data) => { /* ... */ });
// On Linux: may use epoll for network I/O, thread pool for file I/O
// On Windows: uses IOCP under the hood

Common follow-ups: Why do file system operations specifically often rely on libuv's thread pool rather than a truly async OS-native mechanism, unlike network I/O?;What would change about Node.js's architecture if libuv didn't exist and Node had to interact with each OS's I/O API directly?

const asyncHooks = require('node:async_hooks');

const hook = asyncHooks.createHook({
  init(asyncId, type, triggerAsyncId) {
    fs.writeSync(1, `Init: ${type}(${asyncId}) triggered by ${triggerAsyncId}\n`);
  },
});
hook.enable();

Common follow-ups: Why is AsyncLocalStorage recommended over raw async_hooks for the common context-propagation use case?;What performance overhead does enabling async_hooks introduce, and why does that matter for production use?