Node.js Developer Interview Questions

Node.js is a JavaScript runtime designed to execute JavaScript outside a web browser.

It combines a JavaScript engine with runtime APIs and native integrations that make JavaScript practical for servers, command-line tools, automation, networking, and other system applications.

JavaScript engine

Node.js uses the V8 JavaScript engine to parse, compile, and execute JavaScript.

V8 provides the core JavaScript language implementation, including objects, functions, promises, garbage collection, and modern ECMAScript features.

Node.js itself provides capabilities that are not part of the JavaScript language specification.

Examples include:

Runtime versus browser environment

JavaScript is the language, but the runtime determines which host APIs are available.

For example, browser code commonly interacts with DOM APIs such as document, while Node.js applications commonly interact with process, the file system, sockets, and server APIs.

Do not assume every browser API automatically exists in Node.js or every Node-specific API exists in browsers.

Event-driven architecture

Node.js is commonly used for applications that handle many I/O operations because its runtime provides asynchronous APIs and an event-driven execution model.

This does not mean every operation in a Node.js process is asynchronous or that CPU-intensive JavaScript automatically runs in parallel.

Native integration

Node.js coordinates JavaScript execution with operating-system facilities and native libraries for tasks such as file operations, networking, cryptography, and DNS.

Many asynchronous operations ultimately rely on operating-system mechanisms or runtime-managed worker facilities.

process

The global process object exposes information and control related to the current Node.js process.

Examples include:

Buffer

Node.js provides Buffer for working with raw binary data.

Buffers are common when dealing with:

A good Node.js developer distinguishes JavaScript language behavior from functionality supplied by the Node.js runtime.

Node.js supports two primary JavaScript module systems: CommonJS and ECMAScript modules.

CommonJS

CommonJS is the original Node.js module format.

Typical syntax is:

`javascript

const service = require("./service.js");

module.exports = service;

Each CommonJS file is treated as a module with mechanisms including require, exports, and module.exports.

ECMAScript modules

ECMAScript modules, or ESM, are the standardized JavaScript module format.

Typical syntax is:

`javascript

import { service } from "./service.js";

export { service };

Node.js fully supports ECMAScript modules alongside CommonJS.

Explicit module markers

Node.js can determine module format using mechanisms including:

The "type" field therefore affects how .js files within that package scope are interpreted.

Imports and exports

ESM supports standardized static import and export syntax.

CommonJS typically loads modules through require().

Node.js documentation describes require() as using the CommonJS loader while dynamic import() uses the ECMAScript module loader.

Interoperability

Node.js provides interoperability between CommonJS and ESM, but differences in exports, resolution, loading behavior, and available globals can create edge cases.

Code should not assume the two systems behave identically.

Package design

Applications should normally choose one clear module strategy rather than mix formats unnecessarily.

Reusable packages need additional care if they intend to support both ecosystems.

Being explicit about module format in package.json can also improve predictability for Node.js and build tooling.

package.json is a central project and package manifest in the Node.js ecosystem.

It can describe metadata, runtime expectations, scripts, package entry points, module behavior, and dependencies.

dependencies

Production dependencies are packages required for the application or package to function at runtime.

npm documentation distinguishes these from development-only packages.

Examples may include:

devDependencies

Development dependencies are used for development or testing rather than normal application runtime.

Examples may include:

A reusable library should not force its consumers to install development tooling as runtime dependencies.

Semantic versioning

Semantic Versioning commonly represents releases as:

MAJOR.MINOR.PATCH

Conceptually:

npm supports version ranges such as caret and tilde ranges. Its documentation explains that these determine which update categories a dependency can accept.

A version range is not the same as one exact resolved version.

Lockfiles

Package managers can maintain a lockfile containing the resolved dependency graph.

For npm, this is commonly package-lock.json.

The manifest communicates allowed ranges, while the lockfile helps installations reproduce the exact resolved graph represented by that lock state.

Applications should normally commit their lockfile so CI and production builds do not independently resolve an unexpected dependency graph.

Scripts

The scripts field can provide standardized project commands such as:

This allows developers and CI systems to invoke common project actions consistently.

Package metadata

Other important fields can include:

The exact fields required depend on whether the project is an application, reusable library, monorepo package, or command-line tool.

A healthy dependency strategy balances reproducibility with regular, controlled dependency updates rather than leaving versions permanently frozen.

Module resolution determines which file or package is loaded when application code references a module specifier.

Node.js supports different resolution behavior for CommonJS and ECMAScript modules, so developers should understand which loader is active.

Relative modules

A relative specifier identifies code relative to the importing module, such as:

`javascript

import { parse } from "./parser.js";

ES module relative imports commonly use explicit file extensions.

Package imports

A package specifier such as:

`javascript

import express from "express";

is resolved through package resolution rules rather than relative filesystem traversal written by application code.

Package entry points

Historically, packages often relied on fields such as main to identify a primary entry point.

Modern package metadata can use exports to define explicit supported entry points.

Why exports matter

Without a clear package boundary, consumers may import internal implementation files:

`javascript

import helper from "some-package/src/internal/helper.js";

That creates coupling to undocumented file structure.

If the package later reorganizes those files, downstream applications can break even though the supported public API did not conceptually change.

The exports field can expose intentional paths while encapsulating internal implementation files.

Conditional exports

Packages can expose different entry points for defined conditions.

This can support scenarios such as different module formats or environment-specific entry points, but overly complex condition trees can become difficult to test.

Self-referencing and imports maps

Node package metadata also supports package-local mechanisms such as imports for controlled internal aliases.

These can reduce brittle deep relative paths while preserving explicit package boundaries.

Resolution errors

Common causes include:

Do not solve resolution failures by reaching directly into node_modules internals.

Good module architecture makes dependencies and public boundaries explicit and keeps application code independent of package-internal directory layouts.

Production Node.js applications run as operating-system processes and should manage configuration and lifecycle deliberately.

Environment configuration

process.env exposes environment variables to the Node.js process.

Environment variables are strings or absent values and should be treated as untrusted configuration input.

Validate required configuration during startup rather than discovering hours later that a credential, port, URL, or feature setting was missing.

Useful validation includes:

Do not scatter raw process.env reads throughout business code. Build a validated configuration object near startup and inject required values into application components.

Secrets

Environment variables may carry credentials in some deployment environments, but secrets must not be logged or returned in diagnostics.

Use the deployment platform’s appropriate secret-management mechanism rather than committing credentials into source code.

Signals

Process managers and container orchestrators commonly signal applications when they should terminate.

Applications should respond to termination by beginning graceful shutdown.

Graceful shutdown

A typical sequence is:

1. Mark the process unready where applicable

2. Stop accepting new requests

3. Allow active requests a bounded drain period

4. Stop workers from accepting new jobs

5. Complete or safely return durable work

6. Close database pools

7. Close HTTP clients and other resources

8. Exit

Shutdown must be bounded. A process that waits forever can interfere with deployments and orchestration.

Exit codes

Exit code 0 conventionally communicates normal successful termination, while nonzero values communicate failure conditions to parent processes or orchestration systems.

Do not call process.exit(0) after a fatal initialization error.

Unhandled failures

Unexpected failures should remain observable.

For fatal states, continuing inside a potentially corrupted application can be more dangerous than allowing the process manager to restart a clean instance.

Recovery behavior depends on the type of failure; applications should not automatically treat every exception as either fatal or safe.

Readiness and health

A process being alive does not prove it can serve traffic.

Production platforms often distinguish liveness from readiness so a process can temporarily stop receiving traffic while it initializes or drains.

Lifecycle behavior should be tested during deployments rather than assumed to work because a signal handler exists.

A large Node.js platform needs intentional boundaries around packages, dependencies, runtime versions, and ownership so teams can evolve independently without turning the repository into one tightly coupled dependency graph.

1. Establish runtime support policy

Define which Node.js versions are supported in development, CI, and production.

Avoid allowing every service to choose an arbitrary runtime version indefinitely.

A platform policy should define:

2. Choose clear module conventions

Standardize whether new code uses ESM, CommonJS, or a deliberate interoperability strategy.

Node.js supports both systems, but mixing them casually introduces unnecessary resolution and tooling complexity.

Packages should declare their intended module behavior explicitly.

3. Define package boundaries

A package should represent a meaningful capability or ownership boundary rather than merely a directory of arbitrary utilities.

Examples include:

Avoid one universal common package containing unrelated functionality used everywhere.

4. Expose explicit public APIs

Use package entry points and exports to expose supported contracts while keeping internal implementation private.

This prevents consumers from coupling themselves to internal files that may change without notice.

5. Control dependency direction

Define which layers may depend on which others.

For example:

Circular package dependencies are a warning that boundaries may be unclear.

6. Manage dependency versions centrally where useful

In a monorepo, workspaces and shared tooling can reduce duplicated dependency management.

However, centralization should not force unrelated applications to upgrade in lockstep without reason.

7. Preserve reproducible installation

Commit lockfiles according to repository strategy and make CI use deterministic installation behavior.

The build should not depend on whatever packages happen to exist globally on one developer machine.

8. Separate runtime and development dependencies

Production artifacts should not need the full development toolchain unless the deployment model explicitly requires it.

This reduces installation surface and can reduce security and operational complexity.

9. Establish package publishing policy

For reusable internal or external packages, define:

Semantic versioning is useful only when consumers can trust what version changes mean. npm recommends incrementing major versions for breaking changes, minor versions for backward-compatible features, and patch versions for backward-compatible fixes.

10. Control dependency risk

Dependency policy should cover:

A large node_modules graph creates operational and supply-chain responsibilities.

11. Standardize application lifecycle

Provide shared patterns for:

Do not require every team to rediscover production lifecycle behavior independently.

12. Measure architecture health

Useful indicators include:

The best platform architecture creates a predictable default path while allowing teams to diverge when they have a justified product or technical requirement.

Node.js supports several styles for coordinating asynchronous work, including callbacks and promises.

Callbacks

A callback is a function supplied to another operation so it can be invoked when work completes or an event occurs.

Traditional Node.js APIs commonly use an error-first callback convention:

`javascript

readFile(path, (error, data) => {

if (error) {

handleError(error);

return;

}

use(data);

});

By convention, the first argument represents an error and later arguments contain successful results.

Promises

A promise represents the eventual completion or failure of an asynchronous operation.

A promise can be:

Promise chains use methods such as then, catch, and finally.

`javascript

readFile(path)

.then(use)

.catch(handleError);

Promises improve composition because one asynchronous result can be returned into the next step instead of nesting callbacks repeatedly.

async functions

An async function always returns a promise.

Returning a normal value fulfills that promise, while throwing an exception rejects it.

`javascript

async function loadName() {

return "Alex";

}

Calling loadName() produces a promise rather than the raw string directly.

await

await pauses execution of the current async function until the awaited promise settles.

It does not block the entire Node.js process while asynchronous I/O is pending.

Other event-loop work can continue while the async function is suspended.

Error handling

Promise rejection can be handled using catch() or try/catch around awaited operations.

`javascript

try {

const value = await loadValue();

} catch (error) {

handleError(error);

}

Do not catch an error merely to ignore it. Handle it when the current layer can retry, translate, log useful context, clean up, or produce an appropriate response.

Sequential versus concurrent awaits

These operations execute sequentially:

`javascript

const user = await loadUser();

const jobs = await loadJobs();

If the operations are independent, starting them first and then awaiting their results can allow them to overlap:

`javascript

const userPromise = loadUser();

const jobsPromise = loadJobs();

const [user, jobs] = await Promise.all([

userPromise,

jobsPromise,

]);

Concurrency should still be bounded when the number of operations can become large.

The goal is to use asynchronous syntax without hiding error handling, ownership, or resource limits.

The Node.js event loop coordinates JavaScript callbacks and asynchronous events without dedicating one operating-system thread to each client connection.

JavaScript callbacks executed by the main Node.js event loop run synchronously until they return or otherwise yield through asynchronous behavior.

Event-loop phases

At a high level, the event loop processes categories of work associated with phases such as timers, polling for I/O, and check callbacks.

Developers generally should not build application correctness around subtle phase-ordering assumptions, but understanding the model is useful for debugging latency and ordering problems.

Timers

setTimeout() schedules a callback after at least approximately the requested delay.

A timeout of zero does not mean that the callback executes immediately.

It becomes eligible only after the appropriate scheduling conditions are met.

setImmediate

setImmediate() schedules a callback for the check phase of the event loop.

Its ordering relative to a timer can depend on the context in which both were scheduled, so code should not use the two APIs as a fragile general-purpose ordering mechanism.

process.nextTick

process.nextTick() schedules work to run after the current operation completes before the event loop proceeds normally.

Because next-tick callbacks can continually schedule more next-tick callbacks, excessive use can starve ordinary I/O and delay other event-loop work.

It should therefore be used deliberately rather than as a default replacement for other scheduling mechanisms.

Promise callbacks and microtasks

Promise continuation callbacks, including those created by await, run through microtask scheduling.

Microtasks execute at defined checkpoints around JavaScript callback execution.

This is why promise callbacks may execute before later timer callbacks even when the timer delay is very small.

Run-to-completion behavior

Once a JavaScript callback begins running on the event-loop thread, other JavaScript callbacks do not preempt it halfway through ordinary synchronous code.

Therefore this blocks other work:

`javascript

for (;;) {

// CPU loop

}

Async syntax does not solve this unless the expensive work is partitioned or moved somewhere appropriate.

Practical rule

Keep event-loop callbacks short, avoid recursively filling high-priority scheduling queues, and do not depend unnecessarily on fine-grained callback ordering.

Use the event loop primarily to orchestrate work rather than perform long CPU-bound calculations.

Node.js streams provide interfaces for processing data incrementally rather than materializing an entire payload in memory.

Common examples include files, HTTP requests and responses, compression, sockets, and subprocess input or output.

Readable streams

A readable stream produces data.

Examples include:

Writable streams

A writable stream consumes data.

Examples include:

Duplex streams

A duplex stream is both readable and writable.

Network sockets are a common example.

The readable and writable sides can represent independent directions of data flow.

Transform streams

A transform stream is a duplex stream in which output is derived from input.

Examples include:

Why streaming helps

Suppose a service needs to transfer a multi-gigabyte file.

Reading the entire file into memory before writing it to the client creates unnecessary peak memory usage.

A stream can process bounded chunks as data becomes available.

Backpressure

Backpressure handles the situation where a producer can generate data faster than a consumer can process it.

Writable streams maintain internal buffering.

When writable.write() returns false, the producer should stop writing until the writable stream indicates that it is ready for more data, commonly through the drain event.

Ignoring this signal can cause memory usage to grow because data accumulates faster than it can be consumed.

pipe and pipeline

readable.pipe(writable) coordinates common streaming behavior including backpressure.

For production pipelines involving several streams, stream.pipeline() or the promise-based pipeline API provides stronger error and cleanup handling.

highWaterMark

The high-water mark influences buffering behavior. It is a threshold, not necessarily a hard maximum-memory limit for the complete application.

Changing it should follow measurement rather than assuming a larger value always improves throughput.

Object mode

Streams can also operate on JavaScript values instead of bytes or strings through object mode.

This is useful for pipelines of records, but object count and actual object memory size are different concepts.

Streams are most valuable when processing can remain incremental from source through destination.

Production asynchronous work needs a defined lifetime.

A promise continuing forever after its caller has disconnected or timed out wastes resources and can contribute to overload.

AbortController and AbortSignal

Node.js exposes the web-compatible AbortController and AbortSignal APIs.

An operation that accepts a signal can observe cancellation requested by an owner.

`javascript

const controller = new AbortController();

operation({

signal: controller.signal,

});

controller.abort();

Not every library automatically supports cancellation. Verify the contract of the API being used.

Timeouts

External dependencies should have bounded wait behavior.

Examples include:

Some Node.js APIs accept an AbortSignal directly, including promise-based timer APIs.

A timeout should normally cause the application to stop or abandon related unnecessary work instead of merely reporting that the caller stopped waiting.

Cancellation ownership

Cancellation should flow from an owning operation to work whose result is no longer required.

For example, when an HTTP client disconnects, expensive downstream lookups may be cancellable if they have not crossed an irreversible side-effect boundary.

Do not automatically cancel an operation such as a payment write after its externally visible side effect may already have occurred.

Bounded concurrency

This creates one promise per input immediately:

`javascript

await Promise.all(

ids.map(loadRecord)

);

That may be acceptable for ten IDs but dangerous for hundreds of thousands.

The downstream database, API, file system, and local memory all have finite capacity.

Use a worker pool, semaphore-style limiter, batching, or bounded queue when the input size is not naturally small.

Failure semantics

Define whether one failed operation should:

Promise.all, Promise.allSettled, and explicit task management provide different failure semantics.

Cleanup

Cancellation does not remove the need to close resources.

Use finally blocks or appropriate resource-management APIs to release resources when an operation succeeds, fails, or is aborted.

The core rule is that every asynchronous operation should have an owner, a capacity limit, and a bounded or deliberately long lifetime.

Node.js uses several different execution mechanisms that are often incorrectly described as one generic thread pool.

Event loop

The main event loop executes JavaScript callbacks and orchestrates asynchronous activity.

If application JavaScript performs a long synchronous calculation on the event-loop thread, other callbacks and requests must wait.

This is why CPU-heavy request handling can severely reduce latency and throughput.

libuv worker pool

Node.js also uses a worker pool managed through libuv for selected operations that cannot or should not be completed directly through event-loop-driven operating-system facilities.

Node.js documentation identifies examples including selected:

Application JavaScript does not normally submit arbitrary JavaScript functions directly to this internal worker pool.

worker_threads

The node:worker_threads module creates JavaScript execution environments in additional threads.

Node.js documentation recommends workers primarily for CPU-intensive JavaScript operations and notes that built-in asynchronous I/O is generally more suitable for I/O-heavy work.

Worker threads can communicate using message passing and can transfer or share selected memory structures.

When worker threads help

Examples include:

Do not create a brand-new worker for every small request. Worker creation itself has overhead.

For repeated CPU work, maintain a worker pool and dispatch jobs to existing workers.

Worker pool saturation

The libuv worker pool can also become a bottleneck.

For example, many expensive cryptographic operations may compete with file-system tasks using the same runtime worker resources.

Changing worker-pool sizing should follow measurement rather than being used as an automatic fix.

Processes versus workers

Separate Node.js processes provide stronger memory isolation and can also use multiple CPU cores.

Worker threads have lower-level memory-sharing capabilities but failures and resource contention still need deliberate handling.

Choose between processes and workers based on isolation, communication cost, operational model, memory requirements, and workload.

The critical architectural rule is to protect the event loop from long synchronous CPU work.

A scalable Node.js architecture depends less on creating enormous concurrency and more on keeping each execution resource bounded and responsive.

1. Classify work

Separate operations into categories:

Different workloads belong on different execution paths.

2. Protect the event loop

Node.js documentation emphasizes that event-loop callbacks should remain small because a long-running callback delays other clients.

Avoid performing operations such as:

on the event-loop thread.

3. Stream large data

Large uploads, downloads, exports, and transformations should remain streaming where possible.

For example:

HTTP input → parser → transform → object storage

can operate incrementally rather than buffering the complete payload.

Use backpressure-aware APIs such as stream pipelines so downstream slowness propagates toward producers.

4. Isolate CPU-heavy work

CPU-intensive JavaScript should normally move to a bounded worker-thread pool or another computational service.

Node.js documentation describes worker threads as useful for CPU-intensive JavaScript and not generally beneficial for I/O-intensive work.

Do not create one worker per incoming request without a capacity model.

5. Bound concurrency

Define explicit limits for:

Unlimited concurrency turns temporary downstream slowness into memory exhaustion or cascading overload.

6. Apply backpressure

Every producer-consumer path needs overload behavior.

Possible responses include:

An unlimited in-memory array of pending promises is not a queueing strategy.

7. Propagate cancellation and deadlines

If an HTTP request has already timed out or disconnected, downstream operations whose results are no longer needed should be cancelled when safely possible.

Use AbortSignal with APIs that support it and propagate remaining time budgets through integration layers.

8. Separate durable background work

A detached promise inside a web process is not durable.

Tasks that must survive process restart should use a durable queue or equivalent persistent work mechanism.

Examples include:

9. Manage failure semantics

Define:

Retries without limits can amplify outages.

10. Observe event-loop and resource saturation

Monitor signals such as:

A process can have low CPU while still being constrained by downstream capacity.

11. Scale horizontally carefully

Running more Node.js processes can use more CPU cores and increase request capacity, but each process may also create additional database and dependency connections.

Increasing application replicas can therefore overload shared downstream infrastructure.

12. Design graceful shutdown

On deployment or termination:

1. Stop accepting new requests

2. Mark the instance unready

3. Drain active requests within a deadline

4. Stop taking new background work

5. Complete or return durable jobs

6. Stop worker pools

7. Close database and network clients

8. Exit

13. Load test failure conditions

Test more than healthy throughput.

Include scenarios such as:

A robust Node.js service should remain predictable when a dependency becomes slow rather than allowing every internal queue to grow without limit.

Node.js provides low-level network capabilities through its built-in modules, allowing developers to create HTTP servers and clients directly.

Server and Client Objects

The native node:http module provides http.createServer(), which listens for network connections and emits request events.

Each HTTP transaction is modeled using two streams:

HTTP Methods

HTTP methods communicate the intended action on a resource:

Node.js exposes the incoming method via req.method as an uppercase string.

HTTP Headers

Headers provide metadata about the request or response. Common headers include:

Node.js automatically normalizes incoming header names to lowercase, so req.headers['content-type'] should be used instead of camelcase variants.

Status Codes

Status codes categorize the outcome of the HTTP request:

Developers must set the status code before writing response body content using res.statusCode or res.writeHead(). Sending headers after starting the body write triggers a "headers already sent" runtime exception.

Modern Node.js web applications rely on routing and middleware pipelines to organize how HTTP requests are received, processed, and answered.

Routing

Routing is the mechanism of matching incoming request parameters (such as the URI path and HTTP method) to specific execution logic.

Web frameworks (like Express or Fastify) abstract native route parsing. Instead of writing complex if/else logic over req.url, developers declare routes declaratively:

`javascript

app.get("/users/:id", getUserHandler);

Middleware

Middleware represents intermediate functions executed in a chain before reaching the final route handler.

Each middleware function has access to the request object, response object, and a callback to trigger the next step in the pipeline (commonly called next).

Middleware functions are executed sequentially and can:

Request-Response Lifecycle

1. Connection: The client establishes a TCP connection, and the Node.js server receives HTTP data.

2. Parsing: The runtime parses headers and initializes request/response streams.

3. Global Middleware: Request matches global middleware (e.g., CORS, logging, body parsing).

4. Router Matching: The router identifies the matching route definition.

5. Route-Specific Middleware: Executes middleware specific to the matched route (e.g., authentication check).

6. Controller Handler: The request reaches the final route handler, which performs business logic.

7. Serialization: Handler writes data to the response stream.

8. Teardown: The connection closes, and buffers are flushed.

Designing robust REST APIs in Node.js requires validating external input before it reaches database layers, structuring resource collections safely, and returning predictable error formats.

Schema-Based Input Validation

External requests should be treated as untrusted data. Validation should check query parameters, URL path variables, and request body content at the boundary of the application.

Using schema validation libraries (such as Zod, Joi, or Ajv) provides compile-time safety and runtime enforcement:

Collection Pagination

Returning unlimited database records in a single query can cause high memory usage, slow database performance, and eventual OOM (Out Of Memory) crashes.

Structured Error Responses

Production APIs must not leak raw database stack traces, internal system details, or package dependencies in error responses, as this exposes security vulnerabilities.

Errors should be caught, categorized, and formatted into structured JSON responses. A common standard is RFC 7807 (Problem Details for HTTP APIs):

Securing web APIs requires separating identity verification from permission enforcement, controlling resource access across domain boundaries, and hardening HTTP responses.

Authentication

Authentication verifies who the client is. Node.js applications commonly use:

Secure cookies must set flags including HttpOnly (prevents JavaScript access), Secure (requires HTTPS), and SameSite (prevents CSRF).

Authorization

Authorization determines what an authenticated user is permitted to do. Access control middleware should run after authentication:

Cross-Origin Resource Sharing (CORS)

CORS is a browser-enforced security mechanism, not a backend firewall. It controls whether a web app on one domain can access resources on another.

Security Boundaries

Production Node.js applications should use tools like helmet to configure HTTP headers that protect against common attacks:

Organizing web applications requires decoupling routing layers from database layers, and ensuring all asynchronous exceptions are intercepted before crashing the runtime.

Asynchronous Error Handling

Express 4 does not automatically catch unhandled promise rejections generated inside asynchronous route handlers or middleware. If an exception occurs inside an async handler without an explicit try/catch block, the error does not propagate to global error-handling middleware:

`javascript

app.get('/users', async (req, res) => {

const users = await db.getUsers(); // Rejection crashes server or hangs request

res.json(users);

});

To solve this, developers must wrap async handlers in a utility function that routes caught rejections to next(error):

`javascript

const asyncHandler = fn => (req, res, next) => {

Promise.resolve(fn(req, res, next)).catch(next);

};

Express 5 and Fastify handle asynchronous rejections natively.

Dependency Injection (DI)

Avoid importing database clients or service instances directly into HTTP routing controllers. Hardcoded imports couple controllers to specific database connections, making unit testing and stubbing difficult.

Instead, use dependency injection:

Production Node.js APIs must survive localized node failures, protect downstream databases from traffic spikes, and offload CPU-intensive operations away from the HTTP event loop.

1. API Gateways & Edge Routing

Do not expose individual Node.js services directly to the public web. Route traffic through an API Gateway (e.g., Kong, AWS API Gateway) or reverse proxy (e.g., NGINX):

2. Distributed Rate Limiting

In-memory rate limiters (e.g., storing IP counts in a local JS Map) fail in distributed environments because state is not shared across horizontal instances, and application restarts reset limits.

3. Decoupling Synchronous Operations

HTTP request-response cycles should complete within milliseconds. CPU-intensive operations (such as processing files, generating reports, or sending batch emails) block the Node.js event loop, degrading API response times for all clients.

4. Circuit Breakers

API instances should prevent cascading failures when external services become slow. Use circuit breakers (e.g., using opossum): when failure thresholds are crossed, the circuit opens, failing fast immediately instead of exhausting Node.js HTTP connection pools while waiting for timeouts.

Database access in a Node.js service should be treated as a bounded shared resource rather than as an unlimited set of independent connections.

Database connections

Opening a new database connection can involve network setup, authentication, and server-side resource allocation.

Creating a new connection for every query can therefore be inefficient and can overwhelm the database under load.

Connection pools

A connection pool maintains reusable connections that can be borrowed by application operations.

A pool normally provides benefits such as:

The pool should remain bounded.

If each application process is allowed to create a very large number of connections, horizontally scaling the application can exhaust the database even when each individual process appears correctly configured.

Acquire and release

When an operation explicitly checks out a client from a pool, that client must be returned even when the query fails.

A finally block is commonly appropriate for this lifecycle.

Single queries versus transactions

Many database clients allow simple independent queries to be executed directly through the pool.

Transactions are different because every statement in one transaction must execute using the same database connection.

For example:

1. Begin transaction

2. Insert application

3. Insert audit record

4. Commit

Executing those statements through arbitrary pooled connections would not create one transaction.

Commit and rollback

Commit only after the complete logical database operation succeeds.

If an error occurs before completion, rollback before returning the client to the pool.

Keep transactions short

Avoid holding an open transaction while performing unrelated work such as:

Long transactions can hold connections and database locks unnecessarily.

Parameterized queries

Applications should use the database driver’s parameter mechanism rather than assembling SQL by concatenating untrusted values into query strings.

Connection management, transaction ownership, and query safety are all part of correct database design in Node.js.

SQL and NoSQL describe broad families of database approaches rather than one simple performance comparison.

The correct choice begins with application requirements.

Relational databases

Relational databases such as PostgreSQL organize data into relations with explicitly defined structure and support SQL querying.

They are often a strong fit when an application has:

Examples include applications involving users, subscriptions, payments, applications, permissions, and other highly related records.

Document-oriented databases

Document databases such as MongoDB store records as documents and can naturally represent nested structures that are often accessed together.

They may fit workloads where:

This does not mean document databases have no schema or transactions.

Applications still need data contracts, validation, indexes, and consistency decisions.

Model from access patterns

Ask questions such as:

Avoid technology stereotypes

Do not choose NoSQL merely because an application might become large.

Relational databases can scale substantially, and poor modeling can make either database family perform badly.

Likewise, do not choose SQL only because the data appears structured if the workload is naturally document-oriented.

Data-access boundaries

Business logic should not depend unnecessarily on raw driver behavior throughout the entire application.

A repository or data-access layer can be useful when it creates a meaningful boundary around persistence concerns.

However, adding generic repository abstractions that merely mirror every driver method can create unnecessary complexity.

Operational concerns

Database selection should also consider:

The goal is to choose the data model and operational system that best matches the workload rather than starting with a fashionable database category.

A healthy Node.js test suite uses different test levels because no single type of test provides complete confidence.

Unit tests

Unit tests exercise small pieces of behavior with minimal infrastructure.

They work well for:

Unit tests should normally be deterministic and fast.

Integration tests

Integration tests verify collaboration with real components or realistic infrastructure.

Examples include:

Mocks cannot prove that SQL is valid or that a real database schema matches application assumptions.

Node.js test runner

Node.js includes the node:test module for defining and executing tests.

Tests can be run using commands such as:

`bash

node --test

The test module supports features including test suites, lifecycle hooks, assertions through Node.js assertion APIs, mocking capabilities, and test configuration.

Mocking

Mocks are useful when a test needs to:

Do not mock every internal function.

Tests that assert private call sequences often become brittle during harmless refactoring.

Prefer dependency boundaries

Instead of monkey-patching many internal modules, design services with explicit collaborators.

For example:

`javascript

new ApplicationService({

repository,

notifier,

});

A test can then provide controlled implementations naturally.

Test failures, not only success

Important cases include:

Determinism

Avoid tests that depend unnecessarily on:

Test the correct boundary

If correctness depends on PostgreSQL constraints, use an integration test against PostgreSQL.

If correctness is pure business logic, a database-backed test may be unnecessary.

Good test suites optimize for useful confidence rather than maximizing test count.

Every value crossing an HTTP boundary should be treated as untrusted input.

This includes:

Input validation

Validate both syntax and business meaning.

Examples include:

Validation helps reject malformed requests early but is not the only security layer.

SQL injection

Do not interpolate user input directly into SQL.

Unsafe:

`javascript

const sql =

"SELECT * FROM users WHERE email = '" +

email +

"'";

Use parameterized queries supplied by the database driver instead.

Parameterized values separate SQL structure from application data.

Cross-site scripting

XSS occurs when attacker-controlled data is interpreted as executable content in a browser.

Node.js APIs returning JSON are not automatically immune if that data is later rendered unsafely by a browser application.

Apply output handling appropriate to the target context and avoid constructing executable HTML from untrusted strings.

Security headers such as a carefully configured Content Security Policy can provide additional browser-side protection.

CSRF

Cross-Site Request Forgery is particularly relevant when a browser automatically attaches authentication credentials such as cookies to cross-site requests.

Defenses depend on the authentication architecture and can include:

An API using explicitly supplied bearer credentials has a different CSRF threat model from a cookie-authenticated browser application.

CORS is not authorization

Cross-Origin Resource Sharing controls which browser origins can access responses through browser-enforced cross-origin rules.

CORS does not authenticate users and should never replace server-side authorization.

Security headers

Express security guidance recommends controls such as TLS, secure cookies, input handling, reducing framework fingerprinting, and appropriate security headers.

Request limits

Apply limits for:

Validation is not only about correctness; bounded inputs also reduce resource-exhaustion risk.

The application should validate, authorize, and safely interpret every request independently rather than trusting the client interface that generated it.

Authentication security involves several independent controls rather than one token or cryptographic algorithm.

Passwords

Never store plaintext passwords.

Password storage should use an intentionally expensive password-derivation or password-hashing design with a unique salt for each password.

Node.js provides cryptographic primitives such as scrypt through the node:crypto module.

Do not invent a custom password algorithm from general-purpose hashes such as simply computing one SHA-256 digest of the password.

Timing considerations

For security-sensitive fixed-length values such as validated message authentication codes, Node.js provides crypto.timingSafeEqual() to support constant-time comparison behavior when used correctly.

It does not replace validation of the surrounding authentication protocol.

Sessions

Server-side sessions typically give the browser an opaque session identifier while application state remains server-side.

Cookie-based session identifiers should normally use appropriate controls such as:

Rotate or invalidate sessions when security-sensitive state changes require it.

JWTs

A JSON Web Token is a signed or otherwise secured token format, not an authorization system by itself.

When validating JWTs, verify applicable properties including:

according to the application protocol.

Do not merely decode a token and trust its claims.

JWTs can be difficult to revoke immediately if the architecture does not include revocation or short-lived token strategies.

Secrets

Do not commit secrets into source control.

Examples include:

Load secrets through an appropriate deployment secret-management mechanism and never log them.

Dependency security

Node.js applications commonly depend on large transitive package graphs.

npm provides audit capabilities for identifying known dependency vulnerabilities.

An audit result still requires engineering judgment because fixes can introduce compatibility changes and not every reported issue has the same exploitability in a given application.

Updates

Do not leave dependencies indefinitely frozen.

Establish a process for:

Authentication and dependency security must be maintained continuously rather than configured once at project creation.

A secure production Node.js platform should assume that application bugs, dependency failures, compromised credentials, malformed requests, and infrastructure failures will eventually occur.

Security therefore needs multiple independent layers.

1. Define trust boundaries

Identify boundaries between:

Every boundary should authenticate, authorize, validate, or constrain communication according to its risk.

2. Separate authentication and authorization

Authentication determines who the caller is.

Authorization determines what that identity may do.

Do not assume that a valid authenticated user may access any object whose identifier they know.

Object-level authorization should verify ownership or required permission for every protected operation.

3. Apply least privilege

Application database accounts should have only the permissions required by their service.

Avoid running ordinary application services with database-superuser credentials.

Likewise, service identities should receive narrowly scoped permissions for queues, storage, secrets, and external infrastructure.

4. Bound database capacity

Connection pools are part of reliability and security.

An unbounded workload can exhaust database connections and produce denial of service even without a sophisticated exploit.

Calculate pool capacity across all application processes and replicas.

5. Own transaction boundaries clearly

Critical state changes should have intentional transaction ownership.

For operations involving database state and external side effects, consider patterns such as:

Do not assume a database rollback can reverse an already completed external side effect.

6. Validate at every external boundary

Validate request structure, size, type, and business meaning.

Then authorize the requested action independently.

Use parameterized database queries and safe framework APIs rather than concatenating executable syntax from user input.

7. Centralize security-sensitive configuration

Manage secrets through approved infrastructure rather than source files or manually distributed environment files.

Define rotation procedures for:

A secret-management strategy without rotation and revocation is incomplete.

8. Design session and token lifecycle

Define:

Long-lived credentials increase the impact of compromise.

9. Layer testing

Use:

Do not depend only on end-to-end tests to detect authorization bugs.

10. Maintain dependency security

Node.js applications can include hundreds or thousands of transitive packages.

Track:

Automated tooling should surface risk, while engineers evaluate applicability and safe upgrade paths.

11. Audit sensitive activity

Record security-relevant events such as:

Audit records should be protected from casual modification and should avoid unnecessarily storing secrets.

12. Minimize information disclosure

Clients should receive controlled error responses.

Internal traces, SQL strings, filesystem paths, secrets, and implementation details should remain in protected diagnostics rather than public responses.

13. Protect availability

Security also includes resilience against resource exhaustion.

Bound:

Rate limits and overload controls should be applied at appropriate boundaries.

14. Harden deployment

Production services should run with only necessary operating-system, container, filesystem, and network privileges.

Current Node.js releases also provide a permission model that can restrict selected runtime access to capabilities such as filesystem, child processes, workers, and other resources when appropriate for the deployment model.

Runtime permission controls complement application authorization; they do not replace it.

15. Design for incident response

Know how to:

A secure architecture is not one that assumes compromise is impossible. It limits blast radius and makes detection and recovery practical.

Performance optimization should begin with measurement rather than assumptions.

A slow Node.js service can be constrained by very different resources, and each bottleneck requires a different solution.

Start with user-visible metrics

Useful metrics include:

An average latency alone can hide slow tail requests.

Measure runtime behavior

Important Node.js process metrics can include:

Node.js provides performance measurement APIs through node:perf_hooks.

performance.eventLoopUtilization() can help determine how busy the event loop has been during a measured interval.

High event-loop utilization together with high request latency can indicate that JavaScript callbacks or synchronous work are consuming too much event-loop time.

CPU bottleneck

Symptoms may include:

Possible causes include:

CPU-heavy JavaScript may require algorithmic optimization, partitioning, worker threads, or a separate compute service.

I/O bottleneck

A service can have low CPU while still being slow because it spends most of its time waiting on:

Measure dependency latency separately from application execution time.

Database bottleneck

Look at:

Optimizing JavaScript will not fix a missing database index.

Memory bottleneck

Increasing heap usage, frequent garbage collection, or process termination can indicate allocation pressure or a memory leak.

Representative workloads

Test with realistic data sizes and concurrency.

A function that appears fast for ten records may behave very differently with one million records.

Optimize one constrained resource at a time

After identifying a bottleneck:

1. Capture a baseline

2. Change one significant factor

3. Repeat the workload

4. Compare the same metrics

5. Verify correctness

Performance work is successful when it improves the metric users or systems actually care about without creating unacceptable reliability or maintainability costs.

One Node.js process does not automatically make ordinary application JavaScript use every CPU core for request execution.

Production services commonly scale by running multiple processes or multiple application instances.

Multiple processes

Separate Node.js processes can execute independently on different CPU cores.

Node.js provides process-oriented capabilities through APIs such as:

Production deployment platforms may also run multiple independent Node.js containers or virtual-machine processes without requiring application code to manage clustering directly.

Request distribution

Traffic can be distributed through mechanisms such as:

Each application instance handles a portion of incoming requests.

Stateless request handling

If required user state exists only in one process memory, another replica may not have access to it.

For horizontally scaled applications, shared durable or distributed state commonly belongs in systems such as:

This does not mean a process cannot have local caches. Local data simply should not be treated as globally authoritative unless the architecture guarantees it.

Sessions

If authentication sessions are stored only in process memory, requests routed to another instance may not find them.

Solutions can include:

Affinity can reduce some symptoms but also creates operational coupling.

Connection multiplication

Scaling from two processes to twenty processes may multiply:

Therefore scaling the application tier can overload shared dependencies.

CPU-heavy work

Additional web processes can increase CPU utilization across cores, but CPU-heavy operations may still be better isolated through worker threads or dedicated workers rather than competing directly with latency-sensitive HTTP handling.

Graceful termination

Each process should support graceful shutdown so deployments do not abruptly terminate active requests or leave resources unmanaged.

Horizontal scalability therefore requires both multiple execution units and architecture that does not depend on one process being the permanent owner of important state.

JavaScript uses garbage collection, but garbage collection cannot reclaim an object that remains reachable from live application references.

A Node.js memory leak therefore often means the application accidentally retains objects that are no longer logically needed.

Common retention sources

Examples include:

Memory metrics

process.memoryUsage() exposes process memory information including values associated with heap and resident memory.

Watch trends over time rather than one isolated measurement.

A service may legitimately allocate more memory under load and later reclaim it.

A suspicious pattern is memory that continually increases across repeated equivalent workloads without stabilizing.

Heap versus process memory

The V8 JavaScript heap is only part of total process memory.

Node.js applications may also allocate memory through:

Therefore heap metrics and process RSS can move differently.

Garbage collection

Frequent garbage collection can increase latency and CPU cost even when memory does not ultimately exhaust the process.

Allocation rate matters in addition to retained heap size.

Heap snapshots

V8 heap snapshots can show objects and retaining relationships at a moment in time.

Comparing snapshots before and after a repeatable workload can help identify object types that continue accumulating.

Heap snapshots must be used carefully in production.

Node.js documentation warns that generating a heap snapshot requires additional memory roughly comparable to the existing heap and can therefore cause out-of-memory termination on constrained processes.

EventEmitter listeners

Repeatedly adding listeners without removing them may indicate retention bugs.

Node.js warns when listener counts exceed configured thresholds, but increasing the threshold should not be the automatic response to a genuine leak.

Investigative process

A useful workflow is:

1. Confirm memory growth under repeatable load

2. Determine heap versus non-heap growth

3. Inspect allocations and retained objects

4. Compare diagnostic snapshots

5. Find retaining references

6. Fix lifecycle ownership

7. Repeat the same workload

Do not treat garbage collection tuning as the first solution when the application is retaining data indefinitely.

Node.js exposes several diagnostics mechanisms because different production problems require different evidence.

Performance hooks

node:perf_hooks provides APIs for measuring runtime timing and performance characteristics.

Useful capabilities include:

Use these for targeted measurements and runtime telemetry.

Inspector

The node:inspector module interfaces with the V8 inspector protocol.

Inspector-compatible tooling can support activities such as:

Profiling should be performed on representative workloads because a profile from idle development traffic may tell little about production bottlenecks.

Diagnostic reports

Node.js diagnostic reports provide a JSON-formatted snapshot containing information useful for problem determination.

Reports can include information such as:

They can be triggered in circumstances including fatal errors, selected signals, and programmatic requests.

Be careful with diagnostic output because operational reports may contain environment or runtime information that should be protected.

Current Node versions provide options for excluding environment and selected networking information from reports when appropriate.

Diagnostics channel

node:diagnostics_channel provides named channels for publishing diagnostic messages.

Instrumentation libraries can subscribe to those channels without requiring business logic to be tightly coupled to one monitoring implementation.

The API is stable in current Node.js documentation.

Logs are not profiles

Adding more logs is not an effective substitute for CPU profiling or allocation analysis.

Use the tool that answers the actual question.

For example:

Production safety

Diagnostics can consume CPU, memory, disk space, or expose sensitive information.

Use bounded collection, protected storage, and sampling where appropriate.

The goal of observability is to gather enough evidence to diagnose failures without turning diagnostics themselves into a reliability or security problem.

A service eventually receives more work than one of its resources can process.

Scalable systems therefore need explicit overload behavior.

Capacity is multi-dimensional

A Node.js service can saturate through:

Increasing one resource may simply move the bottleneck somewhere else.

Bound concurrency

Do not allow arbitrarily many operations to execute simultaneously.

For example, if the database pool supports 20 active connections, scheduling 20,000 immediate database operations does not create 20,000 units of useful database parallelism.

Most operations will wait while consuming memory and application bookkeeping.

Bound queues

An unlimited in-memory queue converts temporary overload into increasing memory consumption and latency.

A bounded queue requires an explicit policy when it reaches capacity.

Possible actions include:

Backpressure

Node.js streams have built-in mechanisms for propagating consumer capacity toward producers.

Do not ignore writable backpressure signals simply because buffering initially appears to increase throughput.

Load shedding

When capacity is exhausted, rejecting some new work can protect active requests and preserve overall system availability.

Serving fewer requests successfully is often better than accepting everything and timing out nearly all requests.

Deadlines

Queued work needs a useful lifetime.

If a request has already exceeded its deadline, processing it later may consume capacity for a result nobody needs.

Propagate cancellation where safe.

Downstream isolation

Use separate limits for independent dependencies.

A slow analytics service should not necessarily consume every connection required by a critical authentication service.

Event-loop saturation

If event-loop utilization or delay indicates JavaScript execution is saturated, adding more promises to the same process cannot solve the problem.

Reduce synchronous work, isolate CPU tasks, or add appropriately bounded execution capacity.

Observe queue age

Queue length alone is not enough.

A queue of 100 operations processed in milliseconds differs greatly from 100 operations that have waited several minutes.

Monitor:

Capacity management should make overload predictable rather than allowing resources to fail accidentally.

A production Node.js architecture should be designed around finite resources and predictable failure behavior rather than assuming the runtime can accept unlimited concurrent work.

1. Keep request processes responsive

The primary HTTP process should spend most of its time orchestrating I/O and executing relatively small units of JavaScript.

Move long CPU-intensive JavaScript away from latency-sensitive event-loop execution.

Worker threads can provide parallel JavaScript execution for suitable CPU-heavy workloads.

2. Scale horizontally

Run multiple Node.js processes or service replicas behind a load-balancing layer.

Do not require a particular process to permanently own important user state unless the architecture deliberately provides that guarantee.

3. Externalize authoritative state

Store durable shared state in appropriate systems such as:

Process memory remains useful for local caching and temporary computation but should not silently become the only durable system of record.

4. Bound every resource

Define maximums for:

Unlimited internal capacity eventually becomes an outage mechanism.

5. Separate dependency budgets

Do not let one failing integration consume every application worker or outbound socket.

Maintain per-dependency limits, deadlines, and retry strategies.

Critical dependencies may require separate resource pools from optional ones.

6. Protect the event loop

Monitor event-loop utilization and latency.

Avoid synchronous CPU-heavy work in hot paths.

If event-loop saturation rises, investigate CPU profiles and synchronous callbacks instead of simply adding more asynchronous promises.

7. Design backpressure

Large data paths should remain streaming when possible.

A slow downstream consumer must be able to reduce upstream production rather than forcing unlimited buffering.

8. Use durable work for must-complete jobs

An in-process promise disappears when the process terminates.

Use durable background infrastructure for work such as:

Consumers should be retry-safe and idempotent where duplicate delivery is possible.

9. Control retries

Retries need:

A retry storm can turn a partial downstream problem into a system-wide outage.

10. Measure saturation

Monitor:

Node.js provides runtime instrumentation capabilities through APIs such as perf_hooks, diagnostics channels, diagnostic reports, and the V8 inspector ecosystem.

11. Scale based on the constrained resource

If the database is saturated, adding more HTTP replicas may worsen the incident.

If one process is CPU-bound but the database has capacity, more processes or worker capacity may help.

Scale based on measurement rather than request count alone.

12. Isolate failures

One dependency should not be allowed to cascade through the complete platform.

Use bounded pools, separate queues, timeouts, and controlled degradation.

Optional features should fail independently where the product permits it.

13. Handle deployment gracefully

When an instance receives a termination signal:

1. Mark it unavailable for new traffic

2. Stop accepting new requests

3. Drain active requests within a deadline

4. Stop accepting new background work

5. Finish or return durable work safely

6. Close database and HTTP clients

7. Stop worker pools

8. Exit

14. Diagnose production safely

Diagnostic reports, profiles, and heap snapshots can provide valuable evidence, but they also have operational cost.

For example, Node.js documentation warns that heap snapshot generation can require substantial additional memory.

Run invasive diagnostics deliberately and protect generated artifacts.

15. Test failure and overload

Load tests should include:

A scalable architecture is not merely one that handles high traffic when every dependency is healthy. It remains understandable and bounded when capacity is exceeded.