🔄 Event Loop and Asynchronous Architecture

Why I/O Is the Bottleneck

To understand the event loop you first have to feel just how slow input/output is compared to raw computation. The numbers below are hard to grasp in nanoseconds, so the third column scales everything up as if a single CPU instruction took one whole second.

Read that last row again: if a CPU instruction took one second, a round-trip network request across the planet would take five years. A synchronous program would sit frozen for that entire "trip," accomplishing nothing.

🍳 The kitchen analogy: A blocking program is a chef who puts a pot on to boil and then stands there watching it, refusing to chop vegetables or prep the next dish until the water bubbles. Asynchronous programming is the chef who starts the water, moves on to other tasks, and comes back only when the timer rings.

Asynchronous Programming

Asynchronous programming lets your program start a slow operation and keep doing other work, handling the result later via a callback, Promise, or await. Node.js fires off many I/O operations at once and reacts to each as it completes.

How the Event Loop Works

The event loop coordinates four moving parts. Understanding how they hand work to each other is the key insight of this whole lesson.

Phases of the Event Loop

Each turn ("tick") of the loop moves through a fixed sequence of phases. Each phase drains its own queue of callbacks before moving on:

1. Timers — runs callbacks whose setTimeout/setInterval delay has elapsed.
2. Pending I/O callbacks — handles a few deferred system callbacks (e.g. some TCP errors).
3. Poll — the workhorse: retrieves new I/O events and runs most I/O callbacks (file reads, incoming requests).
4. Check — runs setImmediate() callbacks, designed to fire right after the poll phase.
5. Close callbacks — cleanup callbacks such as socket.on('close', ...).

Predicting Execution Order

Here's the classic puzzle. What order do these logs appear in?

console.log('1: Start');

setTimeout(() => {
  console.log('4: setTimeout callback');
}, 0);

Promise.resolve().then(() => {
  console.log('3: Promise microtask');
});

console.log('2: End');

1: Start
2: End
3: Promise microtask
4: setTimeout callback

Walk through it: the two synchronous console.log calls run first (1, then 2). When the main script finishes and the stack empties, Node drains the microtask queue — so the resolved Promise's callback (3) runs next. Only then does the loop reach the timers phase and run the setTimeout callback (4), even though its delay was 0.

The same principle explains why file reads and timers registered early in your code run after the rest of the synchronous script: they're offloaded, and their callbacks only run once the stack is clear.

Callbacks → Promises → Async/Await

Node.js's async patterns have evolved to make the same logic dramatically more readable. Compare the three generations reading two files in sequence.

1. Callbacks (the original)

import fs from 'node:fs';

fs.readFile('file1.txt', 'utf8', (err, data1) => {
  if (err) return console.error(err);
  fs.readFile('file2.txt', 'utf8', (err, data2) => {
    if (err) return console.error(err);
    console.log(data1, data2);
  });
});

Add a few more steps and the nesting marches off the right edge of the screen — the infamous "callback hell" or "pyramid of doom."

2. Promises

import { readFile } from 'node:fs/promises';

readFile('file1.txt', 'utf8')
  .then((data1) => readFile('file2.txt', 'utf8')
    .then((data2) => console.log(data1, data2)))
  .catch((err) => console.error(err));

Flatter and with a single .catch() for errors — a real improvement.

3. Async/await (the modern standard)

import { readFile } from 'node:fs/promises';

async function readBoth() {
  try {
    const data1 = await readFile('file1.txt', 'utf8');
    const data2 = await readFile('file2.txt', 'utf8');
    console.log(data1, data2);
  } catch (err) {
    console.error(err);
  }
}
readBoth();

const [data1, data2] = await Promise.all([
  readFile('file1.txt', 'utf8'),
  readFile('file2.txt', 'utf8'),
]);

Pitfalls & Best Practices

// BAD — busy CPU work on the main thread
function countPrimes(max) {
  let count = 0;
  for (let i = 2; i <= max; i++) {
    let prime = true;
    for (let j = 2; j < i; j++) if (i % j === 0) { prime = false; break; }
    if (prime) count++;
  }
  return count;
}
countPrimes(5_000_000); // nothing else runs until this returns

Do / Don't

Offloading CPU work with a worker thread

import { Worker } from 'node:worker_threads';

function runHeavyTask(data) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./worker.js', { workerData: data });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker exited with code ${code}`));
    });
  });
}

const result = await runHeavyTask({ max: 5_000_000 });
console.log('Done without blocking:', result);

Hands-on Exercise

import { readFile, writeFile, mkdir } from 'node:fs/promises';
import path from 'node:path';

async function processFile(file) {
  try {
    const content = await readFile(file, 'utf8');
    const words = content.split(/\s+/).filter(Boolean).length;
    const summary = { file, words, chars: content.length };

    await mkdir('output', { recursive: true });
    const outName = path.basename(file, path.extname(file)) + '.json';
    await writeFile(path.join('output', outName), JSON.stringify(summary, null, 2));
    return summary;
  } catch (err) {
    if (err.code === 'ENOENT') {
      console.warn(`Skipping missing file: ${file}`);
      return null;
    }
    throw err;
  }
}

const files = ['a.txt', 'b.txt', 'missing.txt'];
const results = (await Promise.all(files.map(processFile))).filter(Boolean);
console.log(`Processed ${results.length} files`, results);

Summary & Quiz

📚 Further Reading

• The Node.js Event Loop, Timers, and process.nextTick()
• Don't Block the Event Loop
• Worker Threads Documentation
• Using Promises (MDN)

🚀 What's Next?

You've now completed the Node.js foundation. Next we switch languages entirely and look at Python for backend development — you'll see how the same server-side concepts (routing, async, databases) reappear in a very different but equally powerful ecosystem.