Node.js Internals Interviewers Ask About

Interviewers at the 4+ years level do not ask "what is Node?". They ask why a setTimeout runs after a promise, why a hash blocks other file reads, what happens when a write is faster than the disk, and how you stop a server without dropping requests. A good answer names the part (V8, libuv, threadpool, OS) and shows a small experiment.

This lesson skips the basics. For modules, Express, middleware and the first look at the event loop, see Full-Stack Q&A, Lesson 06. For promises, async/await, the browser loop and ordering puzzles, see Lesson 16. For a short look at blocking and workers, see Backend, Lesson 10. For the test tools Jest and Vitest, see Lesson 21. Here we go one level deeper and add the newer built-in tools of Node 22.

Words used in this lesson

• V8 is the JavaScript engine (made for Chrome) that Node uses to run your code and manage memory. libuv is the C library that gives Node its event loop, timers, file and network I/O, and a pool of helper threads.
• The event loop is a loop that waits for events (a timer is due, a socket has data) and calls the matching JavaScript function (a callback). It runs on the main thread.
• A phase is one step of the loop, with its own queue of callbacks.
• The call stack is where the JavaScript that is running right now lives. A microtask is a small job (a promise reaction, or queueMicrotask) that runs as soon as the stack is empty. The nextTick queue is a separate Node-only queue that runs even before microtasks.
• The threadpool is a small, fixed group of helper threads inside libuv. Some work that cannot be done without blocking (file reads, DNS lookups, some crypto and compression) is sent there.
• Blocking means the main thread is busy and cannot run other callbacks. Event loop lag is how late a timer fires because of it.
• A stream is a way to process data piece by piece (a chunk) instead of all at once. Backpressure is the signal "slow down, I cannot take more yet" from the consumer back to the producer. highWaterMark is the size at which a stream says it is full.
• A worker thread is another JavaScript thread in the same process, with its own V8 and event loop. A child process is a separate OS process. A cluster is a set of child processes that share one server port.
• AsyncLocalStorage keeps a value that follows an async call chain, like a per-request variable.
• A garbage collector (GC) frees memory of objects that nothing can reach any more. The heap is the memory area for JavaScript objects. A heap snapshot is a file that records every object in the heap.
• A signal is a short message from the OS to a process, like SIGTERM ("please stop") or SIGKILL ("stop now, no choice"). Graceful shutdown means stopping in an orderly way: finish current work, close resources, then exit.
• Stability index is the label in the Node docs for how safe an API is to rely on: Stable (2) is safe, Experimental (1) may change, Active development (1.1) is still being built, Legacy (3) is kept but not recommended.

Part 1. What runs where

your JavaScript  --->  V8 (runs it, one thread)     |     vNode core (fs, net, http, crypto ...)  --->  libuv                                                |-- event loop (main thread): timers, sockets, callbacks                                                |-- threadpool (4 threads by default): fs, dns.lookup, zlib, some crypto                                                `-- OS facilities: epoll on Linux, kqueue on macOS, IOCP on Windows

The libuv design document says it clearly: network I/O is always done on the loop's own thread with non-blocking sockets and the best OS mechanism (epoll on Linux), and a thread pool is used for file system operations and DNS (getaddrinfo, getnameinfo). So "Node is single threaded" is true for your JavaScript, and false for the whole process. A Node process always has more threads: I counted the entries in /proc/self/task inside a tiny script and got 7 (the main thread, V8 helper threads and the libuv workers).

Part 2. The event loop, phase by phase

The libuv docs list one iteration of the loop. Mapped to Node, the main phases are:

Two details from the libuv document that people forget:

• Before blocking in the poll phase, libuv computes how long it may wait. The libuv rules: the timeout is 0 if the loop was told not to wait, if it is being stopped, if there is nothing active, if idle handles are active, or if handles are closing. In every other case it waits until the nearest timer is due, or forever if there is no timer. (That setImmediate callbacks make the poll phase skip the wait is my reading of the behaviour: in my runs immediates always ran right after the I/O callbacks, before a new timer check.)
• A timer is never "exactly on time". A timer says "run after at least N ms". If the loop is busy, it runs later.

Where microtasks and process.nextTick fit

They are not phases. After the JavaScript stack empties, Node runs the nextTick queue until empty, then the microtask queue (promises, queueMicrotask) until empty. This happens after each callback, not once per phase. I ran this:

setTimeout(() => { console.log('timer 1'); Promise.resolve().then(() => console.log('  microtask from timer 1')); process.nextTick(() => console.log('  tick from timer 1')); }, 0);setTimeout(() => console.log('timer 2'), 0);

It printed timer 1, tick from timer 1, microtask from timer 1, and only then timer 2. So between two timers the queues are emptied (the nextTick queue first). The docs of process.nextTick say the queue "is fully drained after the current operation on the JavaScript stack runs to completion and before the event loop is allowed to continue".

The ordering experiment

In a CommonJS file, run as node order1.js:

setTimeout(() => console.log('timeout 0'), 0);setImmediate(() => console.log('immediate'));process.nextTick(() => console.log('nextTick'));Promise.resolve().then(() => console.log('promise microtask'));queueMicrotask(() => console.log('queueMicrotask'));console.log('sync');

Output: sync, nextTick, promise microtask, queueMicrotask, timeout 0, immediate.

Rule: sync code, then nextTick, then microtasks, then the loop phases. But look at what changes in other places (all of these I ran):

Two things to learn from the table:

1. In an ES module, the promise runs before nextTick. The reason is that the module itself is evaluated inside a promise job, so the microtask queue is already being drained when your code adds to the nextTick queue. This is the best "trap" of the topic. (The cause is my reading of the behaviour; the order is what I measured.)
2. Inside an I/O callback, setImmediate always beats setTimeout(0). The loop is in the poll phase, and the next phase is check (immediates), then the next iteration reaches timers.

And in the main module the order of setTimeout(0) and setImmediate is not guaranteed. I measured it two ways. From a file (node order1.js, 20 runs) the timeout came first in 20 of 20. With node -e (100 runs, twice) the immediate came first in 93 and 94 of 100. The reason is a race: setTimeout(f, 0) is really 1 ms, and whether 1 ms has already passed when the loop first checks timers depends on how long the start-up took. Never depend on it.

Part 3. The threadpool and what uses it

The libuv docs say the pool is used for all file system operations, getaddrinfo and getnameinfo, and for user code queued with uv_queue_work. Its default size is 4, set with the UV_THREADPOOL_SIZE environment variable, and the absolute maximum is 1024. The Node CLI docs list what uses it in Node:

The Node dns docs warn that dns.lookup() "is implemented as a synchronous call to getaddrinfo(3) that runs on libuv's threadpool" and can have surprising effects; dns.resolve() does not use the pool.

I ran 8 crypto.pbkdf2 jobs at the same time (each is CPU work of about 285 ms when run alone on my machine):

const crypto = require('node:crypto');const t0 = performance.now();for (let i = 1; i <= 8; i++) {  crypto.pbkdf2('pw', 'salt', 400_000, 64, 'sha512', () =>    console.log(`job ${i} finished at ${Math.round(performance.now() - t0)} ms`));}

The conclusions that hold on any machine: (1) the pool really is a queue with a fixed number of workers (two waves with 4 threads); (2) a bigger pool does not help CPU-bound work once it passes the number of CPU cores (my machine has 4, and 8 threads gave no speedup); (3) a bigger pool helps when threads mostly wait (slow disk, slow DNS). The exact milliseconds are mine.

The real-world bug is this: a slow thing in the pool (many big file reads, a slow DNS server) delays unrelated things in the pool, such as password hashing. If all four threads wait for a DNS server, every fs.readFile waits too. Fixes: raise UV_THREADPOOL_SIZE (it must be set when the process starts, because the docs say setting it inside the process "is not guaranteed to work"), avoid dns.lookup for hot paths (use an address, a cache, or dns.resolve), or move CPU work to worker threads.

Part 4. Streams and backpressure

A stream moves data in chunks, so a 2 GB file does not need 2 GB of memory. There are four kinds: Readable (a source), Writable (a destination), Duplex (both, like a socket) and Transform (a duplex that changes data, like gzip).

Each stream has an internal buffer. The highWaterMark is the size at which it says "full". The v22.22.0 docs say it defaults to 65536 bytes (64 KiB), or 16 objects in object mode. I checked with code: new Readable().readableHighWaterMark and new Writable().writableHighWaterMark both gave 65536, and an object-mode stream gave 16. This default was raised in v22.0.0 (the docs list the change "bump default highWaterMark"); in older versions it was 16 KiB. That is a nice trap if someone says "16 KB".

Backpressure

writable.write(chunk) returns false when the internal buffer has reached the highWaterMark. The stream still accepts the data (it does not throw), but it is telling you to stop writing until the 'drain' event. If you ignore it, the data piles up in memory. I wrote 200 MB (3,200 chunks of 64 KiB) into a slow writable (1 ms per chunk) in two ways:

// ignoring the signal                      // respecting itslow.write(chunk);                          if (!slow.write(chunk)) await once(slow, 'drain');

Both finished in about 3.7 seconds, because the writable was the bottleneck either way. The only difference was memory: the whole 200 MB sat in RAM when I ignored the signal. (The conclusion is the buffer size, which does not depend on my machine.)

You rarely write this by hand. pipe() and pipeline() do it for you, and so does for await (const chunk of readable).

pipe() or pipeline()

readable.pipe(writable) handles backpressure, but not errors: the Node docs say that if the readable emits an error, the destination is not closed automatically and you must close every stream yourself. I ran it with a source that fails:

• With src.pipe(dst) the error went to the source's handler, and dst.destroyed stayed false (an open stream: a leak).
• With pipeline(src, dst, callback) the callback got the error and dst.destroyed was true.

So use pipeline (from node:stream, or the promise version from node:stream/promises):

import { pipeline } from 'node:stream/promises';import { createReadStream, createWriteStream } from 'node:fs';import { createGzip } from 'node:zlib';await pipeline(createReadStream('big.log'), createGzip(), createWriteStream('big.log.gz'));

The await finishes only when everything is flushed, and errors close all streams. Compression here uses the threadpool (Part 3).

Part 5. worker_threads, cluster and child_process

All three give you more than one thread of work. They solve different problems.

The worker_threads docs say workers "are useful for performing CPU-intensive JavaScript operations. They do not help much with I/O-intensive work", because the built-in async I/O is already more efficient. They also list that in a worker process.exit() stops only that thread, signals are not delivered to it, and process.env is a copy (unless you pass SHARE_ENV).

Experiment: a CPU job on the main thread or in a worker

I ran fib(38) (a deliberately slow recursive function) once on the main thread and once in a worker, while a 10 ms timer measured how late it fired:

// ticker: worst lag = how much later than 10 ms a tick ranconst ticker = setInterval(() => {  const now = performance.now();  worstLag = Math.max(worstLag, now - last - 10);  last = now;}, 10);// mode 'main':   fib(38) here// mode 'worker': new Worker(__filename) runs fib(38) and posts the result back

The worker is not faster (a little slower here, because it must start a new V8). The point is that the main loop stayed responsive. For a server this decides whether other users wait. To watch lag in production, use monitorEventLoopDelay() from node:perf_hooks: in a test, a 300 ms blocking loop showed a max delay of 308 ms.

In real servers do not create a worker per request. Keep a pool of workers (libraries such as piscina do this) and send them jobs.

How cluster shares a port

The cluster docs describe two ways. The default on all platforms except Windows is round robin: the primary process accepts connections and hands them to workers in turn. The other way (SCHED_NONE) gives the listening socket to the workers and lets the OS decide; the docs warn that this is often very unbalanced and report loads "where over 70% of all connections ended up in just two processes, out of a total of eight". You choose with cluster.schedulingPolicy or NODE_CLUSTER_SCHED_POLICY (rr or none). I started 4 workers and made 40 requests, each on a new connection, and counted per worker:

Today many teams run one Node process per container and let the platform (for example Kubernetes) run several copies, instead of using cluster. Both are valid; the difference is who manages the copies. Remember that workers in a cluster do not share memory, so an in-memory cache or a rate limiter counter is per process.

Part 6. AsyncLocalStorage

Passing a request id through every function is tedious. AsyncLocalStorage (from node:async_hooks) keeps a store that follows the async chain started inside run(). The module is Stable in the v22.22.0 docs.

const { AsyncLocalStorage } = require('node:async_hooks');const als = new AsyncLocalStorage();const log = (msg) => console.log(`[req ${als.getStore()?.id ?? '-'}] ${msg}`);async function db() { await sleep(20); log('after db'); }       // never receives the idhttp.createServer((req, res) => {  als.run({ id: req.headers['x-id'] }, async () => {            // the store lives for this call tree    log('start'); await db(); await sleep(5); log('end'); res.end('ok');  });});

I sent three requests at the same time (ids a, b, c). Every log line had the right id, even after the awaits, and a line logged outside of run() printed -. This is the right tool for request ids in logs, trace ids, and the current user in a transaction helper.

Gotchas:

• The context is lost when you break the async chain. If you put a callback in your own queue and call it later from somewhere else, getStore() returns undefined. In my test a function queued inside als.run('A', ...) and called from a later timer saw undefined. A function wrapped with AsyncLocalStorage.bind(fn) saw 'B'. (bind and snapshot exist since v19.8.0 and v18.16.0.) Connection pools and custom queues are the usual places where it is lost.
• Do not use it as a global variable. Keep what you store small and read-only.
• In the v22.22.0 docs run() and getStore() are stable, but enterWith(), exit() and disable() are marked Experimental. Prefer run().
• Do not confuse it with the old async_hooks.createHook(). The async_hooks page is marked Experimental ("Please migrate away from this API, if you can") and says "We strongly discourage the use of the async_hooks API".

Part 7. Memory and garbage collection

The basics

V8 splits the heap into a young generation (new, small objects; cleaned often and fast by a "Scavenge") and an old generation (objects that survived; cleaned less often by a "Mark-Compact"). Most objects die young, so this is efficient. I turned on node --trace-gc and saw lines like Scavenge 4.4 (5.1) -> 3.7 (6.1) MB, 1.28 ms and, with big live data, Mark-Compact 89.3 (108.5) -> 85.5 (121.6) MB, 302 ms. Note that a Mark-Compact can take hundreds of milliseconds on a large heap.

process.memoryUsage() returns five numbers (from the docs):

So a leak of Buffers shows in arrayBuffers and rss more than in heapUsed. The limit for the old generation depends on your machine's memory (on my 16 GB machine v8.getHeapStatistics().heap_size_limit was about 8,240 MB). You can change it with --max-old-space-size=SIZE (in MiB). Setting it to 64 gave a reported limit of 112 MB, so the number you set is not exactly the number you get.

When the heap is full, the process dies: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory. I made one happen with --max-old-space-size=24, and the process ended with exit code 134 (an abort).

A leak you can see

A cache with no limit is the most common leak. I added 50,000 entries per round to a Map that is never cleaned, forced a full GC (node --expose-gc) and printed the heap:

round 1: entries=50000  heapUsed after full GC = 18 MB (start 4 MB)round 2: entries=100000 heapUsed after full GC = 32 MBround 3: entries=150000 heapUsed after full GC = 49 MBround 4: entries=200000 heapUsed after full GC = 62 MB

The key signal is memory that still grows after a full GC. Memory that goes up and then down is normal. Memory that keeps a rising floor is a leak. The usual causes: unbounded caches and arrays, listeners added but never removed, timers never cleared, closures that keep big objects, and global maps keyed by request.

Tools: --inspect and heap snapshots

• node --inspect starts the inspector. The default address is 127.0.0.1:9229. I started it on port 9333 and curl http://127.0.0.1:9333/json/list returned the target, so Chrome DevTools can attach through chrome://inspect. The docs warn that binding the inspector to a public address is insecure: anyone who can reach it can run code in your process. Use an SSH tunnel instead.
• v8.writeHeapSnapshot() writes a snapshot file. For a heap with 100,000 small objects the file was 20.5 MB and writing it took 1.2 seconds. The docs warn that it blocks the event loop and that it needs memory about twice the size of the heap, with a risk of the OOM killer ending the process. Do it on one instance that you have removed from the load balancer.
• --heapsnapshot-signal=SIGUSR2 writes a snapshot when the process gets that signal (kill -USR2 <pid>). I did this and got a Heap.<date>.<pid>...heapsnapshot file. It is a runtime switch you can keep on in production if you accept the cost above.
• --heapsnapshot-near-heap-limit=N writes snapshots as the heap approaches its limit. The docs mark it Experimental. In my OOM test it wrote a 74 MB snapshot just before the crash.

The method for a leak: take a snapshot, run traffic, take a second snapshot, then in DevTools (Memory tab) use the Comparison view to see which object types grew, and follow the retainers (what keeps them alive) up to a root. Three snapshots (before, after, after again) make growth clear. For Buffer leaks watch arrayBuffers. In production also graph heapUsed, rss, GC pause time and event loop lag.

Part 8. Built-in tools in Node 22

The test runner (node:test)

No install needed. Files named *.test.js, *-test.js, *_test.js, test-*.js, test.js or inside a test/ folder are found automatically by node --test (from the docs). Note that *.spec.js is not on the list: I ran a a.spec.js and a a.test.js and only the .test.js ran. (In 22.22.0 the same patterns for .ts files are also matched unless you pass --no-experimental-strip-types.)

const { describe, it, mock } = require('node:test');const assert = require('node:assert/strict');const { total } = require('./price.js');describe('total()', () => {  it('multiplies price by qty and applies the rate', () => {    const rate = mock.fn(() => 2);                       // a function that records its calls    assert.equal(total([{ price: 5, qty: 3 }], rate), 30);    assert.equal(rate.mock.callCount(), 1);  });  it.todo('discount codes');});

What I saw: with --test-reporter=spec the output has check marks and a summary (tests 5, pass 4, todo 1). The default reporter depends on the output: the docs say spec is used when stdout is a TTY and tap otherwise, and when I piped the output I got TAP. A failing assert.deepEqual printed a diff of the two values and the exit code was 1, which is what CI needs. --test-name-pattern="empty" ran only the matching test. --experimental-test-coverage printed a table of line, branch and function coverage.

Stability, from the docs: the module is Stable. These parts are not: mock timers (mock.timers) are Experimental (Node printed an ExperimentalWarning), node --test --watch mode and code coverage are marked Experimental in the test runner page, and mock.module() is Early development and needs --experimental-test-module-mocks. Snapshot testing (t.assert.snapshot() with --test-update-snapshots) printed no warning when I ran it; the CLI docs say it is no longer experimental since v22.13.0 (the test page gives v23.4.0 for the same change, so the docs disagree a little). For React components, the DOM and rich mocking, Vitest or Jest are still the better fit (Lesson 21); the built-in runner is good for libraries, scripts and plain Node services.

--watch

node --watch app.js restarts the process when the entry file or any file it imports changes. It has been Stable since v22.0.0 (the CLI docs: "Watch mode is now stable"). I changed an imported file and the output was run 1, Restarting 'app.js', run 2. --watch-path=./src restricts what is watched (and turns off watching of imports). The docs say this option is only supported on macOS and Windows; on my Linux machine it worked, both for a single file and for a changed file inside a nested folder. I would trust the docs for portability and test on your own system. It cannot be combined with --eval or the REPL, and it needs a file argument.

A close relative is node --run <script>, which runs a script from package.json (added in v22.0.0). I ran node --run hi and it printed the script's output. The docs show no stability banner for it in v22.22.0. --env-file=.env is also no longer experimental (since v22.21.0).

The permission model

Run with --permission and Node denies, by default, file system reads and writes, child processes, worker threads, WASI and native addons. You open specific doors with flags. It is Stable since v22.13.0 (CLI docs). I ran the same script three ways:

process.permission.has('fs.read', path) checks at run time. Node also printed a SecurityWarning for --allow-child-process: "must be used with extreme caution. It could invalidate the permission model". Stability of the individual flags: --allow-fs-read and --allow-fs-write are stable, but --allow-child-process and --allow-worker are labelled "Active development".

node:sqlite

A SQLite database inside Node, with no extra package. Added in v22.5.0; since v22.13.0 it works without a flag (--no-experimental-sqlite turns it off). Its stability is 1.1 Active development, and Node prints an ExperimentalWarning when you load it. The API is synchronous (DatabaseSync, StatementSync):

const { DatabaseSync } = require('node:sqlite');const db = new DatabaseSync(':memory:');            // or a file pathdb.exec('CREATE TABLE todo (id INTEGER PRIMARY KEY, title TEXT NOT NULL, done INTEGER DEFAULT 0) STRICT');const ins = db.prepare('INSERT INTO todo (title) VALUES (?)');ins.run('write lesson');                            // { lastInsertRowid: 1, changes: 1 }db.prepare('SELECT * FROM todo WHERE id = ?').get(1);   // one row (null-prototype object)db.prepare('SELECT id, title FROM todo ORDER BY id').all();   // array of rows

A NOT NULL violation threw an error with code ERR_SQLITE_ERROR. The bundled SQLite version was 3.50.4. The module exports DatabaseSync, StatementSync, constants and backup. Because every call is synchronous, a slow query blocks the event loop, so it suits scripts, tools, tests and small local-first apps, and not a busy server (use a worker thread, or a client-server database). The docs list no transaction helper (only a read-only database.isTransaction flag), so I use db.exec('BEGIN') and COMMIT myself.

fetch and undici

Global fetch is Stable since v21.0.0 (it was un-flagged in v18). It is built on undici, an HTTP/1.1 client written for Node; process.versions.undici was 6.23.0 here. You cannot require('undici') unless you install it: only fetch, Request, Response, Headers, FormData and WebSocket are global. To tune connections (pool size, keep-alive, proxy), install the undici package and pass a dispatcher: fetch(url, { dispatcher: new Agent({...}) }) (shown in the Node docs). What I checked:

• Keep-alive works by default. 20 sequential requests to a local server opened only 2 sockets.
• A timeout needs a signal. fetch(url, { signal: AbortSignal.timeout(300) }) against a 2-second endpoint rejected with TimeoutError after 304 ms.
• HTTP errors do not reject. A 404 gave ok === false and the promise resolved. Check res.ok.
• Network errors reject with TypeError: fetch failed; the real reason is in error.cause.
• res.body is a web ReadableStream (not a Node stream). Convert with Readable.fromWeb() when you need to pipe it.

Part 9. Graceful shutdown

When a platform stops your app (a deploy, a scale-down), it sends a signal. Platforms such as Docker and Kubernetes send SIGTERM first and SIGKILL after a grace period (see their docs; I did not re-check them here). SIGKILL cannot be caught ("cannot have a listener installed", Node docs), so everything must be done in the time between.

Facts from the Node docs that I confirmed by running:

• A process with no SIGTERM handler exits at once, with code 128 + signal number. I got 143 for SIGTERM and 130 for SIGINT.
• Once you add a listener, the default behaviour is removed: Node no longer exits by itself. You must exit.
• The 'exit' event allows only synchronous work. 'beforeExit' is not emitted for process.exit() or an uncaught exception.
• server.close() stops accepting new connections and, since v19.0.0, also closes idle keep-alive connections. It calls its callback when the remaining connections are gone. server.closeIdleConnections() and server.closeAllConnections() exist (added in v18.2.0).
• Default timeouts of the HTTP server (v22 docs): keepAliveTimeout 5,000 ms, requestTimeout 300,000 ms, headersTimeout the minimum of requestTimeout and 60,000 ms.

The pattern I ran:

let shuttingDown = false;function shutdown(signal) {  if (shuttingDown) return;                          // ignore a second signal  shuttingDown = true;  console.log(`${signal} received: stop accepting, wait for in-flight requests`);  server.close((err) => {                            // called when every connection is gone    // close the database pool, flush logs, stop queue consumers here    process.exit(err ? 1 : 0);  });  server.closeIdleConnections();                     // keep-alive sockets with no request  setTimeout(() => server.closeAllConnections(), 5000).unref();   // hard limit}process.on('SIGTERM', () => shutdown('SIGTERM'));process.on('SIGINT', () => shutdown('SIGINT'));

I started a request that needed 1.5 seconds, sent SIGTERM after 0.3 seconds, then tried a new request. The new request was refused (curl exit 7), the slow request finished and got its answer, then the server logged server closed, cleaning up, and the process exited with code 0.

The order that matters: (1) stop taking new work (and tell the load balancer you are not ready, if you have a health check), (2) finish current work, (3) close databases, queues and other resources, (4) exit, (5) have a time limit that forces the exit, so you never hang. For queue workers, stop pulling new jobs and let the current job finish.

Stable or experimental in Node v22.22.0

Taken from the v22.22.0 docs (and my runs where noted):

On the last row: node t.ts with const x: number = 41; console.log(x + 1) printed 42 on this install with no flag. Type stripping only removes types; it does not support TypeScript features that need code generation, so see the docs before using it for a real project.

Common mistakes

• Relying on the order of setTimeout(0) and setImmediate in the main module.
• Using process.nextTick recursively, or in new code when queueMicrotask would do.
• Believing Node is single threaded, and then being surprised that a slow DNS lookup delays file reads.
• Raising UV_THREADPOOL_SIZE above the CPU count to speed up CPU-bound work.
• Ignoring the return value of write(), and buffering a whole file in memory.
• Using pipe() without error handling, and leaking the destination stream.
• Running CPU work on the main thread inside a request handler.
• Adding SIGTERM or SIGINT handlers that never call process.exit(), so the process hangs.
• Exposing --inspect on a public address, or taking a heap snapshot on a busy instance with little spare memory.
• Treating the permission model as a sandbox for untrusted code.
• Running node:sqlite heavy queries on the main thread of a busy server.
• Forgetting that fetch does not reject on HTTP error status, and has no timeout unless you add one.

Interview questions

Key takeaways

• Node runs your JavaScript on one thread, but the process also has V8 helper threads and a libuv threadpool. Network I/O uses the OS poller, not the pool.
• Order: sync code, then nextTick, then microtasks (after each callback), then the loop phases. In an ES module, promises run before nextTick. setTimeout(0) against setImmediate in the main module is a race.
• The threadpool has 4 threads by default and serves fs, dns.lookup, zlib and some crypto. More threads than CPU cores do not speed up CPU work.
• Respect write() returning false, or use pipeline(). Backpressure saves memory, not time. The default highWaterMark is 64 KiB since v22.0.0.
• Use worker threads to keep the loop responsive, cluster or containers to use all cores, and child_process for other programs.
• AsyncLocalStorage.run() gives per-request context; it is lost if you break the async chain.
• A leak is memory that rises after GC. Compare heap snapshots, and remember that snapshots block the loop and need about twice the heap.
• In v22.22.0: node:test, --watch, --permission and fetch are stable; node:sqlite is in active development; process.nextTick is legacy. The permission model is not a sandbox.
• Shut down on SIGTERM: stop accepting, finish in-flight work, close resources, exit, with a time limit.

What's next

Go back to Lesson 06 and Lesson 16 and try to explain each ordering puzzle in terms of phases and queues. For measuring what these internals cost in a real request path, read Lesson 32.