⚙️ Node.js Architecture and the Event Loop

The Big Picture

Node.js is not one program but a small team of collaborators. Your JavaScript sits on top; underneath, two heavyweights do the real work: V8 executes your code, and libuv handles asynchronous I/O and the event loop. A layer of C++ glue binds them to Node's built-in modules.

V8: The JavaScript Engine

V8 doesn't crawl through your code line by line. It compiles JavaScript into fast machine code, using a pipeline that trades a little startup time for big speed on code that runs often (a "hot path").

• Parser turns source text into an Abstract Syntax Tree (AST).
• Ignition generates bytecode from the AST and runs it.
• TurboFan watches for hot code and recompiles it into highly optimized machine code.
• Garbage collection reclaims memory you no longer reference — automatically.

// 👎 Shape changes depending on inputs — harder to optimize
function makeUser(name, age) {
    const user = {};
    if (name) user.name = name;
    if (age)  user.age = age;
    return user;
}

// 👍 Same shape every time — V8 loves this
function makeUser(name, age) {
    return { name: name ?? '', age: age ?? 0 };
}

The Event Loop & Its Phases

The event loop is a loop that runs as long as there is work to do. Each turn ("tick") it moves through a fixed sequence of phases, and in each phase it drains a specific queue of callbacks. Between every callback it also empties the microtask queue (more on that shortly).

The six phases

1. Timers — runs callbacks scheduled by setTimeout() and setInterval() whose time has elapsed.
2. Pending callbacks — runs certain system-level I/O callbacks deferred from the previous tick.
3. Idle / prepare — internal use only.
4. Poll — retrieves new I/O events and runs their callbacks; the loop may wait here for work.
5. Check — runs setImmediate() callbacks.
6. Close — runs close callbacks like socket.on('close', ...).

Order in action

console.log('1 — start');

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

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

console.log('6 — end');

1 — start
6 — end
4 — nextTick      // microtasks drain first...
5 — promise       // ...nextTick before promises
2 — setTimeout 0  // then the timers phase
3 — setImmediate  // then the check phase

Why this order? All synchronous code runs first (1 and 6). Before the loop advances to any phase, it empties the microtask queue — and process.nextTick callbacks jump ahead of promise callbacks (4 then 5). Only then do the phases run: the timer (2) and the check-phase setImmediate (3).

Microtasks vs Macrotasks

Every async callback is either a microtask or a macrotask. The distinction is the single most useful key to predicting execution order.

The rule the loop follows

1. Run all synchronous code.
2. Drain the entire microtask queue (nextTick callbacks first, then promises).
3. Run one macrotask from the current phase.
4. Drain the microtask queue again.
5. Repeat.

console.log('script start');

setTimeout(() => {
    console.log('setTimeout');
    Promise.resolve().then(() => console.log('promise inside timeout'));
}, 0);

Promise.resolve().then(() => console.log('promise 1'));
Promise.resolve().then(() => console.log('promise 2'));

console.log('script end');

script start
script end
promise 1
promise 2
setTimeout
promise inside timeout

The libuv Thread Pool

"Single-threaded" describes your JavaScript. Behind the scenes, libuv keeps a small pool of background threads (4 by default, configurable up to 1024) for operations the OS can't do asynchronously on its own.

Network I/O usually uses efficient OS mechanisms directly. But file system work, crypto hashing, zlib compression, and some DNS lookups are handed to the thread pool so they don't block the main thread.

const crypto = require('node:crypto');
const start = Date.now();

// Each pbkdf2 hash is CPU-heavy and runs on a pool thread.
for (let i = 0; i < 8; i++) {
    crypto.pbkdf2('password', 'salt', 100000, 512, 'sha512', () => {
        console.log(`Hash ${i + 1} done in ${Date.now() - start}ms`);
    });
}
// With the default pool of 4, the first four finish together,
// then the next four finish together a bit later.

# Linux / macOS
UV_THREADPOOL_SIZE=8 node app.js

# Windows (PowerShell)
$env:UV_THREADPOOL_SIZE=8; node app.js

Blocking vs Non-Blocking

A blocking call stops the single thread until it finishes — meaning every other pending request waits too. A non-blocking call starts the work and returns immediately, letting the loop serve others.

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

// ❌ Blocking — nothing else runs until the read completes
console.log('start');
const data = fs.readFileSync('big.txt', 'utf8');
console.log(`read ${data.length} chars`);
console.log('next');
// Output: start → read ... chars → next

// ✅ Non-blocking — 'next' logs while the disk works
console.log('start');
fs.readFile('big.txt', 'utf8', (err, data) => {
    if (err) throw err;
    console.log(`read ${data.length} chars`);
});
console.log('next');
// Output: start → next → read ... chars

Escaping with Worker Threads

Non-blocking I/O solves waiting, not computing. A genuinely CPU-heavy task (say, resizing thousands of images) will still hog the main thread. The escape hatch is the worker_threads module, which runs code on a separate OS thread with its own V8 instance.

// main.js
const { Worker } = require('node:worker_threads');

function runHeavyJob(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}`));
        });
    });
}

(async () => {
    const result = await runHeavyJob({ numbers: [1, 2, 3, 4, 5] });
    console.log('Result:', result); // main thread stayed responsive throughout
})();

// worker.js
const { workerData, parentPort } = require('node:worker_threads');

function crunch(numbers) {
    let total = 0;
    for (let i = 0; i < 10_000_000; i++) {
        total += numbers.reduce((sum, n) => sum + n * n, 0);
    }
    return total;
}

parentPort.postMessage(crunch(workerData.numbers));

Practice & Quiz

// order.js
console.log('A');

setTimeout(() => console.log('B'), 0);
setImmediate(() => console.log('C'));

Promise.resolve().then(() => console.log('D'));
process.nextTick(() => console.log('E'));

console.log('F');

// Output:
// A
// F
// E   ← nextTick (microtask, highest priority)
// D   ← promise (microtask)
// B   ← setTimeout (timers phase)
// C   ← setImmediate (check phase)

// blocker.js — this freezes everything while it runs
function fib(n) {
    return n < 2 ? n : fib(n - 1) + fib(n - 2);
}
console.log(fib(45)); // blocks the main thread

// fib-worker.js
const { workerData, parentPort } = require('node:worker_threads');
function fib(n) { return n < 2 ? n : fib(n - 1) + fib(n - 2); }
parentPort.postMessage(fib(workerData));

// main.js
const { Worker } = require('node:worker_threads');
const w = new Worker('./fib-worker.js', { workerData: 45 });
w.on('message', (result) => console.log('fib(45) =', result));
console.log('Main thread is still responsive!'); // logs first

Best Practices & Pitfalls

✅ Do

• Prefer asynchronous, non-blocking APIs everywhere in server code
• Offload CPU-heavy work to Worker Threads (or a separate service)
• Use Promise.all() to run independent I/O in parallel
• Keep object shapes stable so V8 can optimize

❌ Don't

• Call *Sync methods on a request's hot path
• Recursively schedule process.nextTick — it starves the loop
• Assume a top-level setTimeout(0) always beats setImmediate — inside I/O it doesn't
• Run tight, long-running loops on the main thread

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

// 👎 Sequential — each await waits for the previous
const a = await fs.readFile('a.txt', 'utf8');
const b = await fs.readFile('b.txt', 'utf8');

// 👍 Parallel — both reads run at once
const [x, y] = await Promise.all([
    fs.readFile('a.txt', 'utf8'),
    fs.readFile('b.txt', 'utf8'),
]);

Summary

📚 Additional Resources

• Node.js — The Event Loop, Timers, and process.nextTick()
• Node.js — Don't Block the Event Loop
• Node.js — Worker Threads API

🚀 What's Next?

Now that you understand how Node runs your code, it's time to use the tools it ships with. Next up: the core modules — fs, path, and http — the built-in building blocks of every Node application.