Node.js · Advanced interview

Your JS callbacks run on one thread, but certain operations can't be done asynchronously by the OS — filesystem work, DNS lookups (getaddrinfo), and crypto like pbkdf2 — so libuv runs them on a small thread pool (default size 4, set by UV_THREADPOOL_SIZE) and posts the results back to the event loop. Network I/O, by contrast, uses the OS's async facilities (epoll/kqueue/IOCP), not the pool. Saturating the pool with heavy crypto or fs work serializes those operations even though the loop looks idle.

For CommonJS, require resolves a specifier through core modules, then node_modules lookups walking up directories, applying extensions and package.json "main"/"exports". The first require executes the module and caches module.exports in require.cache keyed by resolved path, so later requires return the same instance — which is why modules behave like singletons. Mutating that cache or relying on it for state is a common source of subtle bugs.

V8 uses a generational GC: short-lived objects live in a small 'new space' collected cheaply and often; survivors are promoted to 'old space' collected by mark-sweep/compact, which can pause. Large heaps mean longer pauses, and the heap is capped (--max-old-space-size). At scale you keep allocations low and short-lived, avoid retaining big graphs, and watch for GC pauses showing up as latency spikes.

Run one process per core — via the cluster module, a process manager like PM2, or (more commonly now) multiple container replicas behind a load balancer. The key constraint is that processes don't share memory, so your app must be stateless: no in-process sessions or caches you rely on. Shared state moves to Redis or a database, and sticky sessions or a shared store handle anything connection-bound like WebSockets.

Apply backpressure and load shedding: set request timeouts and body-size limits, rate-limit per client, bound concurrency to downstream dependencies (connection pools, queues), and shed or queue excess work instead of accepting unbounded requests. Health checks plus a circuit breaker around flaky dependencies stop a slow dependency from cascading into a full outage.

Measure it directly — monitor.eventLoopDelay (perf_hooks) or a histogram exported to your metrics, and alert when p99 delay rises. To find the cause, profile with --prof or the inspector, capture flame graphs (0x/clinic flame), and look for synchronous hotspots: JSON.stringify of huge payloads, sync crypto/fs, regex backtracking, or large loops. The fix is to move that work off the main thread or chunk it.

On SIGTERM, stop accepting new work (server.close()), let in-flight requests finish within a timeout, drain queues, close database and Redis connections, then exit. You also fail health checks first so the load balancer stops routing to the instance. A hard timeout forces exit if something hangs. This is what makes rolling deploys zero-downtime.

process.on("SIGTERM", async () => {
  server.close();
  await Promise.allSettled([db.end(), redis.quit()]);
  process.exit(0);
});

Treat an uncaughtException as the process being in an unknown, possibly corrupt state: log it, run minimal cleanup, and exit so a supervisor restarts a fresh process — don't try to resume. unhandledRejection should be logged and surfaced (and in newer Node it can also crash by default); the real fix is to attach a .catch or await with try/catch everywhere. Relying on these handlers to keep limping along is a reliability anti-pattern.

It's the same idea at system scale: if you consume from a queue or socket faster than you can process or persist, memory and latency grow until something falls over. You bound it with concurrency limits on consumers, prefetch/ack windows on the message broker, connection-pool limits to the database, and pausing intake when downstream is slow. The principle is to make the slowest stage set the pace, not the fastest.

Validate and sanitize all input against schemas; use parameterized queries or an ORM to prevent injection; set security headers (helmet) and strict CORS; rate-limit and add authn/authz on every route; keep secrets in env/secret managers, never in code; and run least-privilege. Also audit dependencies (npm audit, lockfiles, Dependabot) since most real-world Node vulnerabilities come through the supply chain.

Node projects pull in large, deep dependency trees, so a single compromised or malicious transitive package can run code in your build or runtime. Manage it by pinning with a committed lockfile, auditing regularly, minimizing dependencies, vetting popular/maintained packages, using npm ci in CI, and considering provenance and tools like socket/Snyk. Treat adding a dependency as a security decision, not just a convenience.

worker_threads for CPU-bound work you want parallelized inside the process with shared memory (e.g. image/crypto processing). child_process/spawn to run external programs or isolate crashy work in its own process. A separate service when the work has a different scaling profile, lifecycle, or language, or needs independent deployment. The decision is about isolation, scaling, and failure boundaries, not just performance.