Node.js · Intermediate interview

Each loop iteration moves through phases: timers (due setTimeout/setInterval callbacks), pending callbacks, poll (retrieve I/O events and run their callbacks), check (setImmediate callbacks), and close callbacks. Between every phase — and after each macrotask — Node drains the microtask queues: process.nextTick first, then resolved promises. Understanding this order explains why callbacks fire when they do.

process.nextTick runs before the event loop continues, draining after the current operation and before promises — overusing it can starve I/O. setImmediate runs in the check phase, after the poll phase completes. setTimeout(fn, 0) runs in the timers phase on the next iteration, with a minimum delay. So roughly: nextTick → promises → (loop phases) → setImmediate, while setTimeout depends on timer scheduling.

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("nextTick")); // prints first

Macrotasks are scheduled by the event-loop phases — timers, I/O callbacks, setImmediate. Microtasks are process.nextTick callbacks and promise reactions, and they're drained completely after each macrotask (and between phases) before the loop moves on. That's why a chain of resolved promises runs before the next setTimeout, even a zero-delay one.

Streams process data in chunks instead of loading it all into memory, which is essential for large files or network data. The four types are Readable (source, e.g. fs.createReadStream), Writable (sink, e.g. an HTTP response), Duplex (both, e.g. a TCP socket), and Transform (a duplex that modifies data, e.g. gzip). They let you build memory-efficient pipelines.

Backpressure is when a writable destination can't keep up with how fast a readable source produces data. If you ignore it, memory balloons. write() returns false when the internal buffer is full, signalling you to pause until a 'drain' event; pipe() and pipeline() handle this automatically by pausing the source until the destination catches up. That's why piping is preferred over manual read/write loops.

const { pipeline } = require("stream");
pipeline(src, gzip, dest, (err) => { if (err) handle(err); });

pipe() chains streams but doesn't propagate errors or clean up the other streams if one fails, which can leak file descriptors. pipeline() (or its promise form) wires the streams together AND forwards errors and destroys all streams on failure, giving you a single completion callback. For production pipelines, pipeline is the safer default.

A thrown error or rejected promise inside an async handler isn't automatically caught by Express (in Express 4), so it can hang the request. You either wrap handlers in a try/catch that calls next(err), use an async-wrapper helper, and then define a single error-handling middleware with four arguments (err, req, res, next) at the end to format the response consistently. Express 5 forwards rejected promises to that error middleware automatically.

const wrap = fn => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);
app.use((err, req, res, next) => res.status(err.status || 500).json({ error: err.message }));

Never trust client input. Use a schema validator (Zod, Joi, express-validator) to check body, query, and params against an explicit schema in a middleware, rejecting bad requests with a 400 before they reach business logic. This prevents type bugs, injection, and malformed data, and gives you a single place to document the contract.

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that blocks a web page from calling an API on a different origin unless the API opts in with the right response headers. You configure it (e.g. the cors middleware) when your frontend is served from a different origin than your API, specifying allowed origins, methods, and whether credentials are allowed. It's enforced by the browser, not the server.

It blocks the single event-loop thread, so every other request stalls until it finishes — throughput collapses and timeouts appear. Fixes: offload the work to a worker_thread or a separate process/service, break it into chunks that yield to the loop, or move it to a queue/background worker. The rule is to keep the main thread for orchestration and I/O, not number-crunching.

cluster forks multiple Node processes that share a listening port, each with its own memory and event loop — good for scaling a stateless HTTP server across CPU cores. worker_threads run multiple threads inside one process sharing memory via SharedArrayBuffer — good for CPU-bound work you want to parallelize without full process overhead. Cluster for scaling requests; worker_threads for parallel computation.

Watch RSS/heap growth over time; if it climbs and never recovers under steady load, you likely have a leak. Take heap snapshots with the Chrome DevTools inspector (--inspect) at intervals and compare retained objects, or use clinic/heapdump. Common causes are unbounded caches, listeners never removed, closures holding large objects, and globals that keep growing.