Node.js Runtime Fundamentals

Node.js is V8 (Google's JS engine) glued to libuv (a C library for async I/O), plus a standard library written partly in JS and partly in C++. When you run node server.js, V8 parses and JITs your code, and libuv hands out a single OS thread to execute it. That single thread is the "main thread" everyone talks about.

In Node 22 LTS the JS side is fast, but it is still one thread. Anything CPU-heavy you put on it blocks the entire process: every connection, every timer, every request handler. Node's bet is that most servers are I/O-bound, not CPU-bound. When that bet holds, you get high throughput on cheap hardware. When it doesn't, you reach for worker threads or another process.

Your JS runs synchronously to completion. When it does I/O it hands the work to libuv (or the OS) and registers a callback. libuv spins a loop that, on each iteration (a "tick"), drains queues in a fixed order. Each completed I/O callback runs to completion before the next one starts. There is no preemption. If a callback never returns, the loop never advances.

This is why a synchronous JSON.parse of a 200 MB string stalls every other request: nothing else can run until that callback finishes.

Each tick walks these phases in order. Microtasks (Promises, queueMicrotask) drain between every callback.

Two queues run BETWEEN phases, not inside them: the process.nextTick queue and the Promise microtask queue. Both drain fully before the loop moves on. process.nextTick drains first, then Promises.

This matters because a tight process.nextTick loop can starve I/O forever — the poll phase never runs. Promises are similar but slightly safer (one microtask per .then). Rule of thumb: use Promises for application code; reach for process.nextTick only inside library internals where you need to defer until the current call stack unwinds but before any I/O.

setTimeout(fn, 0) schedules in the timers phase; setImmediate(fn) schedules in the check phase, right after poll. So if you're inside an I/O callback (poll phase), setImmediate always fires before setTimeout(fn, 0). Outside of I/O — say, in your top-level script — order is racy and depends on how long startup took.

const fs = require('node:fs');
fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
  process.nextTick(() => console.log('nextTick'));
  Promise.resolve().then(() => console.log('promise'));
});
// nextTick, promise, immediate, timeout

Memorize that order. It comes up in interviews and in real bugs.

Node's standard library exposes most I/O twice: a non-blocking async version (fs.readFile) and a synchronous version (fs.readFileSync). The async one returns instantly and calls you back when libuv finishes; the sync one parks the main thread until the OS returns. On a server, the sync version is almost always wrong: while it's parked, no other request can be handled.

The sneakier blockers are pure-JS: JSON.parse on huge payloads, regex with catastrophic backtracking, bcrypt.hashSync, big synchronous loops. The event loop can't help you with those. Measure with node --prof or the built-in perf_hooks.monitorEventLoopDelay if a route feels laggy under load.

When you genuinely need CPU parallelism — image resizing, ML preprocessing, big JSON transforms — use the node:worker_threads module. Each worker is a separate V8 isolate with its own event loop, communicating via postMessage (structured clone) or SharedArrayBuffer for zero-copy. They are NOT a substitute for async/await; they exist to keep CPU work off the main thread.

import { Worker } from 'node:worker_threads';
const w = new Worker('./hash-worker.js', { workerData: { rounds: 12 } });
w.on('message', (hash) => console.log(hash));

For request-level fanout, prefer a worker pool (e.g., piscina) so you're not spinning up a thread per request.

Honest state of the world: npm ships with Node and Just Works; lockfile is package-lock.json. pnpm is the choice for monorepos — content-addressed store, hardlinks, fast installs, strict module resolution. bun (the runtime) ships its own package manager that is the fastest installer by a wide margin, but using bun install to feed a Node runtime is a tradeoff: occasional resolution differences vs npm/pnpm.

Pick one and stick with it per repo. For most teams in 2026: pnpm for app monorepos, npm for libraries you publish, bun if you're already running the bun runtime end-to-end. Don't mix lockfiles in the same project.

When your p99 latency creeps up under load, it's usually event-loop lag. Two tools:

import { monitorEventLoopDelay } from 'node:perf_hooks';
const h = monitorEventLoopDelay({ resolution: 20 });
h.enable();
setInterval(() => {
  console.log('p99 lag ms:', (h.percentile(99) / 1e6).toFixed(1));
}, 5000);

Anything consistently over a few milliseconds means something on the main thread is starving I/O. Pair with --inspect + Chrome DevTools to capture a CPU profile and find the offender. The fix is almost never "add more threads" — it's "move that one synchronous hot path off the main loop."

Hold these four ideas and most Node behavior follows:

1. One thread runs your JS. Anything synchronous it does blocks everything else.
2. libuv runs the loop in fixed phases; I/O callbacks fire in poll, setImmediate in check, timers in timers.
3. Microtasks (process.nextTick, Promises) drain between callbacks, not between phases.
4. CPU-bound work goes to worker threads; everything else stays async on the main loop.

The rest — streams, clusters, AsyncLocalStorage, native addons — is built on top of this model. Get this right and the rest reads like documentation.