Question 1

In an Express 4 application, an asynchronous route handler throws an unhandled error inside a Promise, causing the HTTP request to hang indefinitely until client timeout. Explain why Express 4 cannot automatically catch rejected promises in async middleware and how to fix this using wrapper utilities or migrating to Express 5.

Accepted Answer

Express 4's own error-handling machinery only catches synchronous throws inside route handlers, or errors explicitly passed to next(err). When an async function throws inside a Promise chain and nothing calls .catch() or next(err), the rejection becomes an unhandled rejection that Express never sees — the request just hangs because no response was ever sent and nothing told Express the request failed. Express 4 predates widescale async/await adoption and was never rewired to auto-catch promise rejections from route handlers.

The fix in Express 4 is to wrap every async handler so any rejection is funneled into next(err) automatically, using the express-async-errors package (patches Express's Router to catch rejections) or a small wrapper util:
```js
const asyncHandler = (fn) => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);

app.get('/orders/:id', asyncHandler(async (req, res) => {
  const order = await db.orders.findById(req.params.id); // throws -> caught by wrapper -> next(err)
  res.json(order);
}));
```
Express 5 fixes this at the framework level — route handlers that return a rejected promise are automatically passed to next(err), so this class of bug disappears once you migrate, though you still need a final error-handling middleware (err, req, res, next) to actually respond to the client instead of hanging.

Question 2

A payment webhook endpoint requiring raw cryptographic HMAC validation fails with signature mismatches because a global express.json() middleware has already parsed and modified the request stream. How do you configure route-specific body parsers or use the verify option to preserve raw request buffers?

Accepted Answer

A global express.json() (or body-parser.json()) middleware reads the raw request stream, parses it into a JS object, and effectively consumes the stream — by the time your webhook handler runs, req.body is a parsed object, not the exact bytes the sender signed. Most webhook providers (Stripe, Razorpay, GitHub) compute an HMAC signature over the exact raw byte sequence of the payload; parsing and re-serializing JSON can change whitespace/key order, so recomputing the signature from req.body won't match the header the provider sent.

The fix is to avoid running the global JSON parser on that specific route, capturing the raw buffer before parsing:
```js
app.use('/webhooks/stripe', express.raw({ type: 'application/json' })); // raw Buffer, not parsed
app.use(express.json()); // safe for every other route

app.post('/webhooks/stripe', (req, res) => {
  const sig = req.headers['stripe-signature'];
  const event = stripe.webhooks.constructEvent(req.body, sig, endpointSecret); // req.body is the raw Buffer
  res.sendStatus(200);
});
```
Route order matters — the raw-body middleware for the webhook path must be registered before any general-purpose express.json() that would otherwise apply globally.

Question 3

Your team deploys an Express API behind an AWS Application Load Balancer across 6 auto-scaling container instances. Why does the default in-memory express-rate-limit fail to protect against API abuse, and how do you implement a Redis-backed sliding-window rate limiter?

Accepted Answer

express-rate-limit's default store keeps hit counters in the process's own memory. With 6 auto-scaling instances behind a load balancer, each container has its own independent counter — a client making 100 requests spread round-robin across 6 instances might only hit ~17 requests per instance, sailing under a 100 req/min limit meant to apply globally. Worse, scaling events reset counters entirely since state doesn't survive a restart.

The fix is a shared, centralized store so every instance reads/writes the same counters — Redis is the standard choice:
```js
const { RedisStore } = require('rate-limit-redis');
const rateLimit = require('express-rate-limit');
const redisClient = require('./redisClient');

const limiter = rateLimit({
  windowMs: 60_000,
  max: 100,
  store: new RedisStore({ sendCommand: (...args) => redisClient.call(...args) }),
  standardHeaders: true,
});
app.use('/api/', limiter);
```
For a true sliding window (rather than the fixed-window default), you'd implement it with a Redis sorted set — push a timestamped entry per request, trim entries older than the window, count remaining members — or use a library like rate-limiter-flexible which ships sliding-window and token-bucket algorithms backed by Redis out of the box.

Question 4

An endpoint that queries 500MB CSV exports from cloud object storage and pipes them to the client crashes with Node process OutOfMemory errors under multiple concurrent requests. How do you use Node.js stream.pipeline() to enforce backpressure between the readable source and writable HTTP response stream?

Accepted Answer

res.write() on an HTTP response is backed by a TCP socket with its own OS-level send buffer. If you read data faster than the client (or network) can drain it, and don't respect backpressure, Node buffers the excess in process memory rather than pausing the source — do that for several concurrent large downloads and the heap blows past its limit.

stream.pipeline() automatically pauses the readable source whenever the writable destination's internal buffer is full (write() returns false), and resumes it once the destination emits 'drain'. That backpressure signal keeps memory bounded regardless of how large the underlying data is:
```js
const { pipeline } = require('stream/promises');

app.get('/export', async (req, res) => {
  try {
    const csvStream = getCsvExportStream(); // Readable from cloud storage
    res.setHeader('Content-Type', 'text/csv');
    await pipeline(csvStream, res); // handles backpressure + propagates errors + closes both ends
  } catch (err) {
    if (!res.headersSent) res.status(500).end('export failed');
  }
});
```
pipeline() over manual .pipe() also guarantees that if either side errors or the client disconnects mid-stream, all streams involved get properly destroyed — with raw .pipe() you have to wire that cleanup yourself or leak file descriptors/sockets.

Question 5

A single-page application hosted on a separate subdomain fails to communicate with your Express backend, showing CORS errors on POST requests with custom headers while GET requests succeed. Explain how browser CORS preflight (OPTIONS) handling works and how to properly configure credentials and exposed headers in the cors middleware.

Accepted Answer

For simple requests (GET, or POST with only standard content types like application/x-www-form-urlencoded), browsers send the request directly. Once a request carries custom headers (e.g. Authorization, X-Custom-Header) or a non-simple content type like application/json, the browser first sends an OPTIONS preflight asking the server whether it's willing to accept a real request with these headers/method from this origin. If the server's OPTIONS response doesn't explicitly allow that combination, the browser blocks the actual request before it's even sent — which is why GET can succeed while POST with JSON fails.

Fixing it means configuring the cors middleware to answer preflights correctly, and being explicit about credentials — a wildcard origin is disallowed once credentials are involved:
```js
const cors = require('cors');

app.use(cors({
  origin: 'https://app.example.com',       // must be explicit, not '*', when credentials are used
  credentials: true,                        // allows cookies/Authorization to be sent cross-origin
  allowedHeaders: ['Content-Type', 'Authorization', 'X-Custom-Header'],
  exposedHeaders: ['X-Request-Id'],         // headers the browser JS is allowed to read from the response
}));
```
On the frontend, fetch(url, { credentials: 'include' }) (or axios.defaults.withCredentials = true) is required to actually send cookies with a cross-origin request — configuring only the server side isn't enough.

Question 6

A high-throughput Node.js microservice experiences severe p99 latency spikes across all endpoints whenever a batch of passwords is hashed using synchronous bcrypt. How do you measure event loop delay using perf_hooks.monitorEventLoopDelay and offload CPU-intensive operations to a worker_threads pool?

Accepted Answer

Node runs your JS on a single main thread. bcrypt.hashSync executes the actual hashing computation synchronously on that thread — while it's busy, the event loop cannot process any other callback, timer, or incoming request, so every other in-flight request stalls until the hash finishes. Do this in a batch and every endpoint's p99 spikes, even ones unrelated to password hashing.

perf_hooks.monitorEventLoopDelay() measures exactly this — how long the event loop is delayed between iterations, giving percentile stats you can alert on:
```js
const { monitorEventLoopDelay } = require('perf_hooks');
const histogram = monitorEventLoopDelay({ resolution: 20 });
histogram.enable();
setInterval(() => console.log('p99 lag (ms):', histogram.percentile(99) / 1e6), 10_000);
```
The actual fix is to move CPU-bound work off the main thread using worker_threads, keeping the event loop free to keep serving I/O:
```js
const { Worker } = require('worker_threads');
function hashInWorker(password) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./hashWorker.js', { workerData: { password } });
    worker.once('message', resolve);
    worker.once('error', reject);
  });
}
```
For high throughput you'd wrap this in a worker pool (e.g. piscina) rather than spawning a new Worker per request, since thread creation itself has overhead.

Question 7

An aggregation API executes four independent microservice calls concurrently using Promise.all(). If one optional recommendation service fails, the entire dashboard request fails. How do you refactor the code using Promise.allSettled() to allow partial data rendering and graceful degradation?

Accepted Answer

Promise.all() rejects as soon as any one of its input promises rejects, discarding the results of every other promise — even ones that already succeeded. If the recommendations call fails but user-profile, orders, and notifications all succeeded, Promise.all() throws away all that good data and the whole request fails, even though only one optional piece was missing.

Promise.allSettled() instead waits for every promise to settle and gives you an array of {status, value} or {status, reason} objects, so you can render whatever succeeded:
```js
const results = await Promise.allSettled([
  getUserProfile(userId),
  getOrders(userId),
  getRecommendations(userId), // may fail — not critical
  getNotifications(userId),
]);

const [profile, orders, recommendations, notifications] = results.map(r =>
  r.status === 'fulfilled' ? r.value : null
);

res.json({ profile, orders, recommendations, notifications,
  degraded: results.some(r => r.status === 'rejected') });
```
It's worth distinguishing must-have data from optional data explicitly — if getUserProfile is essential, you'd still want to short-circuit and return an error when that specific promise rejects, rather than silently rendering a broken page; allSettled gives you the raw information to make that call per-field instead of Promise.all's all-or-nothing behavior.

Question 8

An application making hundreds of concurrent outbound HTTPS calls and local file operations suffers unexplainable connection stalls. How does libuv's internal thread pool (UV_THREADPOOL_SIZE) handle asynchronous file I/O and dns.lookup(), and how do you tune threadpool sizing and DNS caching to prevent pool starvation?

Accepted Answer

Node's async I/O for fs operations and dns.lookup() (the OS-resolving variant) doesn't happen for free in the background — libuv delegates it to a fixed-size pool of OS threads, sized by UV_THREADPOOL_SIZE (default 4). Network sockets don't use this pool — they're handled by the OS's async I/O primitives directly — but fs.* calls, dns.lookup, some crypto functions, and zlib all queue onto that same 4-thread pool. Fire off hundreds of dns.lookup() calls plus file reads concurrently and they all compete for just 4 worker threads, queuing up behind whatever's already running — including HTTPS calls that need a fresh dns.lookup() per connection.

Two independent mitigations: increase the pool size, and reduce load on the pool by caching DNS lookups:
```js
process.env.UV_THREADPOOL_SIZE = 16; // must be set before any pool-using module is loaded

const { Agent } = require('https');
const CacheableLookup = require('cacheable-lookup');
const cacheable = new CacheableLookup();
const agent = new Agent({ keepAlive: true });
cacheable.install(agent); // patches the agent to use cached DNS
```
Keep-alive HTTP agents reduce how many fresh connections (and lookups) you need at all, which usually matters more than just raising UV_THREADPOOL_SIZE.

Question 9

A real-time notification gateway leaks 50MB of heap memory per hour. Heap snapshots reveal thousands of detached closure scopes retained inside a singleton EventEmitter's listener arrays. How do you identify leaked listeners using eventEmitter.listenerCount() and ensure clean unsubscription upon client disconnection?

Accepted Answer

An EventEmitter keeps a reference to every listener registered via .on(). If a client connects and you attach a listener closure capturing request-scoped variables (sockets, buffers, user context) onto a long-lived singleton emitter, and never call .off()/.removeListener() when that client disconnects, the listener — and everything its closure references — stays reachable forever. Over thousands of connect/disconnect cycles that's thousands of dead closures the GC can never reclaim.

emitter.listenerCount(eventName) is the quick diagnostic — if that number only grows and never shrinks as connections churn, you've found your leak. Node also warns by default once a single event on one emitter passes 10 listeners (MaxListenersExceededWarning), often the first visible symptom.

The fix is to always pair .on() with a corresponding .off() when the resource goes away:
```js
function handleConnection(socket) {
  const onNotify = (payload) => socket.send(JSON.stringify(payload));
  notificationBus.on('notify', onNotify);

socket.on('close', () => {
    notificationBus.off('notify', onNotify); // critical: without this, onNotify (and socket) leak forever
  });
}
```
Using once() where a callback should fire only once, and AbortController-based cleanup (emitter.on(event, fn, { signal })) removes a whole class of 'forgot to unsubscribe' bugs.

Question 10

Explain why catching and ignoring process.on('uncaughtException') to keep a Node.js process alive is an anti-pattern that leads to corrupted application state, and describe the proper pattern for logging, closing open socket descriptors, and delegating process restarts to an orchestrator.

Accepted Answer

uncaughtException fires only after the stack has already unwound past whatever was executing — by the time your handler runs, you have no idea what state your application is actually in: a database transaction might be half-committed, a mutex might be held forever, in-flight requests might have partially-written responses. Swallowing the exception and letting the process keep running doesn't undo any of that — it just hides the fact that the process is now in an unknown state, so the next request might fail in a completely unrelated, much harder-to-debug way.

The correct pattern is to treat any uncaught exception as fatal: log it with full context, stop accepting new work, let in-flight requests finish within a short deadline, close resources, then exit — leaving the restart decision to your process manager (PM2, Kubernetes, systemd), which is equipped to bring up a fresh, known-good process:
```js
process.on('uncaughtException', (err) => {
  logger.fatal({ err }, 'uncaught exception — shutting down');
  server.close(() => process.exit(1)); // stop taking new connections, then exit
  setTimeout(() => process.exit(1), 10_000).unref(); // force-exit if close() hangs
});
```
The same reasoning applies to unhandledRejection — log and exit rather than ignore, since modern Node terminates the process on an unhandled rejection by default anyway, itself evidence the platform considers silently continuing the wrong behavior.

Question 11

An Express API utilizing Prisma ORM is ported to AWS Lambda. During a traffic surge with 300 concurrent Lambdas, the PostgreSQL database maxes out connections and crashes. Explain why serverless concurrency causes connection pool exhaustion with traditional ORMs and how to mitigate it using RDS Proxy or Prisma Accelerate.

Accepted Answer

A traditional connection pool is designed around a small number of long-lived server processes, each holding open a modest number of persistent connections for the process's lifetime. Lambda breaks that assumption: each concurrent invocation can spin up its own execution environment, each initializing its own Prisma client with its own pool. With 300 concurrent Lambdas each opening even 5 connections, that's 1,500 connections against a Postgres instance that typically caps around 100-500 — the database runs out of connections and starts rejecting new ones.

The fix is to put a connection multiplexer between Lambda and Postgres so thousands of short-lived logical connections share a much smaller pool of real backend connections — RDS Proxy or Prisma Accelerate (or PgBouncer in transaction mode):
```js
const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient({
  datasources: { db: { url: process.env.DATABASE_POOLER_URL } }, // RDS Proxy / PgBouncer endpoint
});
```
It's also worth reusing the Prisma client across warm invocations (initialize outside the handler, not inside it) so a warm Lambda container doesn't open a fresh connection on every request.

Question 12

Using TypeORM's repository.find({ relations: ['author', 'comments'] }) on large datasets creates massive memory overhead and duplicate rows due to relational JOIN cartesian products. How do you refactor complex multi-relation queries using TypeORM's createQueryBuilder or two-phase primary-key queries?

Accepted Answer

relations: ['author', 'comments'] makes TypeORM generate a single SQL query with LEFT JOINs across all three tables. If a post has 1 author and 50 comments, the JOIN produces 50 rows — all with duplicated author data repeated across every row — and TypeORM has to deserialize and de-duplicate all of that back into nested objects in memory. Across large datasets, you transfer and process far more raw data than the final result shape implies.

createQueryBuilder lets you use smarter joins, but the more scalable fix for one-to-many relations is a two-phase query: fetch primary entity IDs first (cheap, no join), then fetch related data separately using IN (...) and stitch it together in application code:
```js
const posts = await postRepo.find({ take: 100, skip: 0 }); // phase 1: just posts, no join
const postIds = posts.map(p => p.id);

const comments = await commentRepo
  .createQueryBuilder('comment')
  .where('comment.postId IN (:...postIds)', { postIds })
  .getMany(); // phase 2: single flat query for all related comments

const commentsByPost = groupBy(comments, 'postId'); // stitch in memory
```
This trades one wide query for two narrow ones, avoiding row duplication entirely and scaling much better as the fan-out ratio grows.

Question 13

A financial ledger service written with Knex.js fails to roll back database modifications when an error occurs inside a nested async helper function. Walk through managing explicit transaction providers (trx), committing, rolling back, and preventing leaked transaction connections in Knex.

Accepted Answer

Knex transactions are scoped to a single transaction object (trx) that must be explicitly passed into every query you want included. If a nested async helper runs its own query using the global knex instance instead of the trx it was handed, that query executes outside the transaction on a different connection — so when the outer transaction rolls back, that helper's write was never part of it and stays committed, leaving the ledger inconsistent.

The fix is disciplined threading of trx through every function that needs to participate, plus wrapping the whole thing so any thrown error triggers automatic rollback:
```js
async function transferFunds(fromId, toId, amount) {
  return knex.transaction(async (trx) => {
    await debitAccount(trx, fromId, amount);   // must accept and use trx, not global knex
    await creditAccount(trx, toId, amount);
    await recordLedgerEntry(trx, fromId, toId, amount);
  });
}

async function debitAccount(trx, accountId, amount) {
  const rows = await trx('accounts').where({ id: accountId }).decrement('balance', amount);
  if (rows === 0) throw new Error('account not found'); // triggers rollback of the whole transaction
}
```
knex.transaction(callback) handles commit/rollback automatically based on whether the callback's promise resolves or rejects — safer than manual trx.commit()/trx.rollback(), and it guarantees the connection is released back to the pool even if you forget something.

Question 14

A background reporting query fetching 40,000 MongoDB documents via Mongoose consumes 800MB of RAM and takes 12 seconds to process. Why does Mongoose Document hydration with getters, setters, and change tracking create such high overhead, and how does .lean() improve performance?

Accepted Answer

A Mongoose Document isn't a plain JS object — it's wrapped with getters/setters for every schema field, change-tracking (isModified, markModified), virtuals, and methods so .save() later works correctly. Building 40,000 of these fully-featured wrapper objects, when you're only reading data for a report, means paying the memory and CPU cost of change-tracking machinery you'll never use.

.lean() tells Mongoose to skip hydration entirely and return plain JS objects straight from the MongoDB driver — no getters, no change tracking, no methods:
```js
const rows = await Report.find({ createdAt: { $gte: startDate } })
  .lean()          // returns plain objects, not Mongoose Documents
  .cursor();        // stream results instead of loading all 40k at once

for await (const doc of rows) {
  processReportRow(doc); // doc is a plain object here, much cheaper to allocate
}
```
Combining .lean() with .cursor() (or .batchSize()) compounds the win: .lean() cuts per-document overhead, and cursoring avoids materializing all 40,000 documents in memory simultaneously, which is what usually turns a slow query into an OOM risk.

Question 15

Running an integration test suite with Jest and Supertest produces the warning: Jest has detected the following 1 open handle potentially keeping Jest from exiting: TCPSERVERWRAP. How do you identify whether the culprit is an active HTTP server listener, an unclosed database pool, or an active timer, and how do you cleanly shut them down in afterAll?

Accepted Answer

That warning means something in your test process created a handle (socket, timer, file descriptor) still active when Jest tries to exit — Jest can't force-close in-process resources safely, so it tells you the type and leaves you to find the source. The usual suspects: an HTTP server you .listen()ed but never .close()d, a database pool still open, or a setInterval/setTimeout never cleared.

Running with --detectOpenHandles gives you a stack trace pointing at where the handle was created, faster than guessing. Once found, close it in afterAll (or afterEach if per-test), matching whatever created it:
```js
let server;
let dbPool;

beforeAll(async () => {
  server = app.listen(0); // random free port for tests
  dbPool = await createTestDbPool();
});

afterAll(async () => {
  await new Promise((resolve) => server.close(resolve)); // closes the TCPSERVERWRAP handle
  await dbPool.end(); // releases pooled DB connections
});
```
For Supertest specifically, passing the Express app directly rather than a listening server means Supertest spins up an ephemeral server per call and normally tears it down itself — the leak is more often a server or pool your own test setup created and forgot to close.

Question 16

When scaling a Node application using PM2 cluster mode across 8 CPU cores, in-memory WebSocket connections and local user session maps stop working because requests hit different worker processes. How do you restructure the backend using a shared Redis adapter and external session store?

Accepted Answer

PM2 cluster mode forks your app into N separate OS processes (one per core) that all listen on the same port via OS-level load balancing, but they do not share memory — each worker has its own V8 heap. Any in-memory Map of WebSocket connections or session data only exists in the process that built it; if a client's next request lands on a different worker via round-robin, that worker has no idea the connection/session exists.

The fix is to externalize that shared state — Redis is the standard choice, both for pub/sub (routing a message to whichever worker holds the target socket) and session storage:
```js
const { createAdapter } = require('@socket.io/redis-adapter');
const { createClient } = require('redis');

const pubClient = createClient({ url: process.env.REDIS_URL });
const subClient = pubClient.duplicate();
io.adapter(createAdapter(pubClient, subClient)); // emit() reaches a socket on ANY worker

app.use(session({
  store: new RedisStore({ client: pubClient }),
  secret: process.env.SESSION_SECRET,
}));
```
For raw (non-Socket.IO) WebSocket servers, you'd hand-roll the equivalent: publish outbound messages to a Redis channel keyed by user/connection ID, and have every worker subscribe and forward messages meant for sockets it owns locally.

Question 17

A TypeScript Node.js microservice Docker image is 1.4GB in size because build tools (e.g., tsc, @types/*, source maps) are bundled into the final container. Design a multi-stage Dockerfile that compiles the code, executes tests, and ships only production dependencies (npm prune --production) on a minimal Alpine/Distroless base.

Accepted Answer

A naive single-stage Dockerfile runs npm install (pulling devDependencies like typescript, @types/*, test runners), compiles TypeScript, and ships that entire filesystem layer into the image that runs in production, none of which is needed at runtime.

A multi-stage build splits this into a build stage (has all dev tooling, compiles and tests) and a much smaller runtime stage that copies only compiled output and production node_modules:
```dockerfile
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci                     # full deps, including devDependencies, for building/testing
COPY . .
RUN npm run build              # tsc -> dist/
RUN npm test                   # fail the build here if tests fail
RUN npm prune --production     # strip devDependencies from node_modules after build

FROM node:20-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
COPY package*.json ./
USER node
CMD ["node", "dist/index.js"]
```
Switching the final stage's base to gcr.io/distroless/nodejs20 shaves the image down further by dropping the shell and package manager entirely, at the cost of losing docker exec -it ... sh for debugging — a reasonable trade for a production image.

Question 18

During Kubernetes rolling updates of a Node service, clients experience sporadic connection resets (ECONNRESET). How do you coordinate server.close(), setting Connection: close headers on active keep-alive sockets, and waiting for the Kubernetes endpoint controller to update iptables before terminating the process?

Accepted Answer

During a rolling update, Kubernetes sends SIGTERM to the old pod and, in parallel, starts removing it from the Service's endpoint list — but that endpoint removal (updating iptables/IPVS rules on every node) isn't instantaneous. If your process reacts to SIGTERM by calling process.exit() immediately, it closes its listening socket and kills still-open keep-alive connections before the cluster has finished routing traffic away, so requests already in flight (or new ones sent in the small window before iptables catches up) hit a closed socket and the client sees ECONNRESET.

The correct sequence is to keep finishing existing requests for a grace period, stop accepting new ones, and only then close the process — combined with a preStop hook giving the networking layer time to converge:
```js
process.on('SIGTERM', () => {
  server.close(() => {           // stops accepting new connections; waits for in-flight ones to finish
    dbPool.end().then(() => process.exit(0));
  });
  setTimeout(() => process.exit(1), 30_000).unref(); // hard cutoff
});
```
```yaml
lifecycle:
  preStop:
    exec:
      command: ["sh", "-c", "sleep 5"]  # gives kube-proxy/iptables time to stop routing here
terminationGracePeriodSeconds: 40
```
Setting Connection: close on responses issued after the shutdown signal also nudges well-behaved clients to open a fresh connection to a still-healthy pod instead of reusing one that's about to disappear.

Question 19

What is the Node.js event loop, and what are its main phases?

Accepted Answer

Node.js runs JavaScript on a single thread, but achieves concurrency for I/O by delegating blocking work (network, disk, timers) to the OS/libuv and processing results through an event loop — a loop that repeatedly checks whether a callback is ready to run and executes it. This is why Node handles thousands of concurrent connections despite being single-threaded: it's never blocking on I/O, not doing anything in parallel on the CPU.

The event loop cycles through phases in order each tick: timers (expired setTimeout/setInterval callbacks), pending callbacks (some deferred system-level callbacks), poll (retrieves new I/O events and executes their callbacks — where most work happens), check (setImmediate callbacks), and close callbacks (e.g. socket.on('close', ...)). Between every phase, all pending microtasks — resolved Promise .then() callbacks and process.nextTick callbacks — get fully drained first.

```js
setTimeout(() => console.log('timer'), 0);
setImmediate(() => console.log('immediate'));
Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));
console.log('sync');
// Output order: sync, nextTick, promise, timer, immediate
```
This matters practically because it explains real bugs — e.g. why a recursive process.nextTick() call can starve the event loop entirely (its queue drains completely before moving on, so I/O never gets a turn).

Question 20

What's the difference between process.nextTick(), queueMicrotask(), and setImmediate() in Node.js?

Accepted Answer

All three schedule a callback for later, but at different priority levels. process.nextTick() queues a callback that runs immediately after the current operation finishes, before the event loop continues to anything else — even before Promise callbacks. queueMicrotask() (and Promise .then()) uses the standard microtask queue, which runs right after the nextTick queue drains but still before the event loop moves to its next phase. setImmediate() is different in kind — not a microtask at all, it schedules the callback for the 'check' phase of the next iteration of the event loop, after I/O callbacks in the current iteration have run.

```js
setImmediate(() => console.log('1: setImmediate'));
process.nextTick(() => console.log('2: nextTick'));
queueMicrotask(() => console.log('3: microtask'));
// Prints: 2: nextTick, 3: microtask, 1: setImmediate
```
nextTick runs first, microtask second, setImmediate last — because the first two both drain before the loop advances at all, and nextTick's queue is checked before the microtask queue specifically in Node's implementation.

Practically: use setImmediate when you deliberately want to yield to I/O before continuing (e.g. breaking up a long CPU loop so pending requests get serviced in between chunks); avoid deeply recursive process.nextTick calls since they can starve the event loop indefinitely.

Question 21

What are the key differences between CommonJS and ES Modules in Node.js, and what interop issues come up when mixing them?

Accepted Answer

CommonJS (require/module.exports) is synchronous and resolves module paths at call time — you can require() conditionally inside an if block. ES Modules (import/export) are statically analyzed — imports are hoisted and resolved before any code runs, which is what lets bundlers tree-shake unused exports, but also means you can't put an import inside a conditional the way you can require.

Node decides which system a file uses based on package.json's "type" field ("module" = ESM, default = CJS) or file extension (.mjs forces ESM, .cjs forces CJS). The interop pain: an ESM file can import a CJS module fairly transparently, but a CJS file cannot require() an ESM-only package synchronously — you need a dynamic import() instead:
```js
async function loadChalk() {
  const { default: chalk } = await import('chalk'); // dynamic import returns a Promise
  console.log(chalk.green('works'));
}
```
This is a genuinely common real-world breakage: a package goes ESM-only in a major version bump, and every CJS codebase depending on it must switch to dynamic import(), pin an older version, or migrate to "type": "module".

Question 22

Explain Node.js Streams and the difference between Readable, Writable, Duplex, and Transform streams.

Accepted Answer

Streams are Node's abstraction for handling data incrementally — chunk by chunk — instead of loading an entire resource into memory at once, essential for large files, network payloads, or anything where you don't know the total size ahead of time. There are four base types: Readable (a source you read from, e.g. fs.createReadStream), Writable (a destination, e.g. fs.createWriteStream or an HTTP response), Duplex (both readable and writable independently — e.g. a TCP socket), and Transform (a special Duplex where what you write in gets transformed and comes back out the readable side — e.g. zlib.createGzip()).

```js
const fs = require('fs');
const zlib = require('zlib');
const { pipeline } = require('stream/promises');

await pipeline(
  fs.createReadStream('access.log'),   // Readable
  zlib.createGzip(),                    // Transform
  fs.createWriteStream('access.log.gz') // Writable
);
```
The reason to reach for streams instead of fs.readFile + process + fs.writeFile is memory: on a 10GB log file, the naive approach holds the whole thing in a Buffer, while the streaming version only ever holds a small chunk (default 64KB highWaterMark) at a time, with backpressure automatically pausing the source if the destination falls behind.

Question 23

What's the difference between Node's cluster module and worker_threads, and when would you use each?

Accepted Answer

Both let a Node app use more than one CPU core, but for different problems. cluster forks multiple full processes, each running your entire app with its own V8 instance and memory space, and the master process load-balances incoming connections across them — aimed at scaling I/O-bound HTTP servers across cores. worker_threads creates threads within the same process that can share memory (via SharedArrayBuffer) and are aimed at offloading CPU-bound computation without blocking the main event loop, while being lighter-weight to spin up than a full process.

```js
// cluster: scale HTTP handling across cores, no shared memory
const cluster = require('cluster');
if (cluster.isPrimary) {
  for (let i = 0; i < require('os').cpus().length; i++) cluster.fork();
} else {
  require('./app').listen(3000);
}

// worker_threads: offload one CPU-heavy task, keep the main event loop free
const { Worker } = require('worker_threads');
new Worker('./resizeImage.js', { workerData: { path: 'photo.jpg' } })
  .once('message', (result) => console.log('resized:', result));
```
Rule of thumb: cluster (or PM2's cluster mode, which does the same thing) solves 'not enough cores handling requests'; worker_threads solves 'one CPU-heavy task is blocking everything else.' They're not mutually exclusive — a clustered app can still use worker threads inside each process.

Question 24

How do you implement graceful shutdown in a Node.js server responding to SIGTERM?

Accepted Answer

When an orchestrator (Kubernetes, PM2, systemctl) wants to stop your process, it sends SIGTERM and then waits a grace period before force-killing with SIGKILL. If your app doesn't listen for SIGTERM, Node's default behavior is to exit immediately — dropping in-flight requests and leaving database connections or file handles in an inconsistent state.

A proper handler stops accepting new work first, lets existing work finish within a bounded time, then closes downstream resources before exiting:
```js
const server = app.listen(3000);

let shuttingDown = false;
async function shutdown(signal) {
  if (shuttingDown) return;
  shuttingDown = true;
  console.log(`${signal} received, shutting down gracefully`);

server.close(async () => {           // stop accepting new connections, wait for active ones
    await dbPool.end();
    await redisClient.quit();
    process.exit(0);
  });

setTimeout(() => process.exit(1), 10_000).unref(); // force exit if shutdown hangs
}

process.on('SIGTERM', () => shutdown('SIGTERM'));
process.on('SIGINT', () => shutdown('SIGINT'));
```
A common mistake is only handling SIGINT (Ctrl+C, useful locally) and forgetting SIGTERM, which is what container orchestrators actually send — an app fine locally can still drop requests on every production deploy if SIGTERM isn't handled.

Question 25

How does Express middleware execution order work, and what does calling next() actually do?

Accepted Answer

Express processes middleware in the exact order registered with app.use()/app.get(), etc. — each receives (req, res, next), and is responsible for either sending a response (ending the chain) or calling next() to hand control to the next matching middleware. If a middleware neither responds nor calls next(), the request hangs forever, a very common beginner bug.

```js
app.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next(); // must call this or the request never proceeds further
});

app.use((req, res, next) => {
  if (!req.headers.authorization) return res.status(401).json({ error: 'unauthorized' }); // ends the chain
  next(); // only reached if authorized
});

app.get('/profile', (req, res) => res.json({ user: 'ok' })); // final handler
```
Calling next(err) with an argument skips all remaining regular middleware and jumps straight to the nearest error-handling middleware (4 parameters: err, req, res, next) — the mechanism express-async-errors and manual async wrappers rely on to route thrown/rejected errors into centralized error handling instead of crashing or hanging the request.

Question 26

How do you prevent SQL injection in a Node.js application when writing raw SQL queries?

Accepted Answer

SQL injection happens when untrusted input is concatenated directly into a query string, letting an attacker inject SQL syntax that changes the query's meaning — e.g. a login field containing ' OR '1'='1 turning a WHERE username = '...' check into something always-true. The fix is to never string-concatenate user input into SQL; use parameterized queries instead, where the driver sends the query and values separately so the database treats values strictly as data, never as executable SQL.

```js
// VULNERABLE — never do this
const bad = await db.query(`SELECT * FROM users WHERE email = '${req.body.email}'`);

// SAFE — parameterized query, values passed separately
const good = await db.query('SELECT * FROM users WHERE email = $1', [req.body.email]);

// Query builders/ORMs parameterize automatically when used normally
const user = await knex('users').where({ email: req.body.email }).first();
```
Parameterization covers the vast majority of cases, but there are edge cases even ORMs don't protect against automatically — e.g. building dynamic column/table names or ORDER BY clauses via string interpolation (those can't be parameterized the same way values can); those need a strict allowlist of valid identifiers instead of ever passing user input directly into that part of the query.

Question 27

Compare JWT-based auth vs session-based auth for a Node backend, including where you should store the token.

Accepted Answer

Session-based auth keeps a session ID in a cookie, with actual user data stored server-side (memory, Redis, DB) keyed by that ID — the server can invalidate a session instantly by deleting that record, but requires a lookup per request and a shared store once you scale past one instance. JWT-based auth puts signed user claims directly in the token itself — the server can verify it cryptographically with no database lookup, scaling beautifully horizontally, but revoking a single token before its expiry is hard without a server-side blocklist, which defeats the 'no lookup' advantage.

Where you store the token matters for security: localStorage is readable by any JS on the page, directly vulnerable to XSS (one injected script exfiltrates every user's token); an httpOnly, Secure, SameSite cookie is not readable by JS at all, closing that vector at the cost of needing CSRF protection.
```js
res.cookie('accessToken', jwt, {
  httpOnly: true,   // JS on the page cannot read this — mitigates XSS token theft
  secure: true,     // only sent over HTTPS
  sameSite: 'lax',  // mitigates CSRF for most navigation-based attacks
  maxAge: 15 * 60 * 1000,
});
```
A common production pattern combines both: a short-lived JWT access token (httpOnly cookie, ~15 min) plus a longer-lived refresh token — you get JWT's stateless verification for most requests while still having a revocation point via the refresh token.

Question 28

bcrypt vs argon2 for password hashing in a Node backend — which would you pick and why?

Accepted Answer

Both are deliberately slow, adaptive hashing algorithms designed to make brute-forcing stolen password hashes expensive — the opposite of a fast hash like SHA-256, which is a liability for passwords since it lets an attacker try billions of guesses per second on cheap hardware. bcrypt has been the industry default for over a decade and is simple to use, but has a fixed, relatively small memory footprint, making it comparatively cheap to attack in parallel on GPUs/ASICs.

Argon2 (specifically Argon2id) won the 2015 Password Hashing Competition and is explicitly memory-hard — you tune not just time cost but memory cost, and since GPU/ASIC parallelism is bottlenecked by memory bandwidth far more than compute, that makes large-scale parallel cracking significantly more expensive for equivalent CPU time.
```js
const argon2 = require('argon2');

const hash = await argon2.hash(password, {
  type: argon2.argon2id,
  memoryCost: 19456, // ~19 MB — OWASP-recommended baseline
  timeCost: 2,
  parallelism: 1,
});
const valid = await argon2.verify(hash, password);
```
For a new project today, Argon2id is the better default per current OWASP guidance; bcrypt remains perfectly acceptable if you're already using it or need broader legacy support — the practical risk in most real breaches is weak or reused passwords, not which of these two you picked.

Question 29

Explain the CAP theorem and how it should influence choosing a database for a Node microservice.

Accepted Answer

CAP theorem says a distributed data store can only fully guarantee two of three properties during a network partition: Consistency (every read sees the latest write), Availability (every request gets a response), and Partition tolerance (the system keeps working despite network splits). Since partitions are a fact of life, the real practical choice is between CP (consistent but may refuse requests during a partition) and AP (available but may serve stale data).

For a Node microservice this becomes concrete: a payments/ledger service wants strong consistency — Postgres or a CP-configured store, because serving a stale balance is worse than briefly refusing a request. A product-catalog or session-cache service usually prefers AP — DynamoDB's default eventually-consistent reads, or Cassandra tuned for availability — because staying up with slightly stale data beats an outage.
```js
// choosing read consistency explicitly, not just picking 'a database'
await dynamoClient.get({
  TableName: 'orders',
  Key: { orderId },
  ConsistentRead: true, // opts into strong consistency for this read, at a latency/cost premium
});
```
The theorem is often mistaught as 'pick 2 of 3 forever' — modern databases let you tune consistency per-operation, so the real skill is knowing which specific reads/writes need strong consistency versus which can tolerate eventual consistency for better availability and latency.

Question 30

How would you implement a circuit breaker in a Node.js service calling an unreliable downstream API?

Accepted Answer

A circuit breaker sits between your service and a downstream dependency, tracking recent failure rate. When failures exceed a threshold, it 'opens' the circuit — immediately failing (or falling back) for subsequent calls without even attempting the downstream request — instead of letting every request pile up waiting on a slow/dead dependency and exhausting your own connection pool. After a cooldown period it moves to 'half-open', letting a small number of test requests through before fully closing again.

```js
const CircuitBreaker = require('opossum');

async function callRecommendationService(userId) {
  const res = await fetch(`https://recs.internal/user/${userId}`);
  if (!res.ok) throw new Error(`upstream ${res.status}`);
  return res.json();
}

const breaker = new CircuitBreaker(callRecommendationService, {
  timeout: 3000,
  errorThresholdPercentage: 50, // open the circuit once 50% of recent calls fail
  resetTimeout: 15000,          // wait before trying again (half-open)
});

breaker.fallback(() => ({ recommendations: [] })); // graceful degradation while open

app.get('/dashboard', async (req, res) => {
  const recs = await breaker.fire(req.user.id);
  res.json({ recommendations: recs });
});
```
The key value isn't just handling the error (a try/catch does that) — it's failing fast once you know the dependency is unhealthy, protecting your own resources and giving the downstream service room to recover instead of being hammered by retries from every caller simultaneously.

Question 31

Explain retry with exponential backoff and jitter — why does jitter matter?

Accepted Answer

A naive retry just calls the failing operation again immediately, which often makes things worse — if a downstream service is struggling under load, an instant retry storm from every failing client adds more load right when it can least handle it. Exponential backoff waits progressively longer between attempts (100ms, 200ms, 400ms, 800ms), giving the downstream system room to recover.

But pure exponential backoff has its own failure mode: if 1,000 clients all started failing at the same moment, they'll all retry at the exact same intervals in lockstep, creating synchronized 'thundering herd' spikes at each round. Jitter — adding a random component to each wait — breaks that synchronization so retries spread out instead of arriving in bursts.
```js
async function fetchWithRetry(url, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      const res = await fetch(url);
      if (res.ok) return res;
      throw new Error(`status ${res.status}`);
    } catch (err) {
      if (attempt === maxRetries) throw err;
      const base = Math.min(1000 * 2 ** attempt, 30_000); // exponential, capped
      const delay = Math.random() * base; // full jitter
      await new Promise((r) => setTimeout(r, delay));
    }
  }
}
```
This 'full jitter' strategy (randomizing between 0 and the exponential ceiling) is what AWS's architecture blog popularized specifically because it empirically produces the lowest overall retry volume and fastest recovery for a fleet of retrying clients.

Question 32

What is an idempotency key, and how do you implement idempotent POST endpoints in a Node backend?

Accepted Answer

POST requests aren't naturally idempotent — calling 'charge $50' twice normally charges $50 twice. But real clients retry all the time (network timeout, client crash before seeing the response), and for a payment, an accidental duplicate charge is a serious problem. An idempotency key is a unique value the client generates once per logical operation and sends with the request; the server uses it to recognize it already processed this exact operation and returns the original result instead of redoing the work.

```js
app.post('/payments', async (req, res) => {
  const idempotencyKey = req.headers['idempotency-key'];
  if (!idempotencyKey) return res.status(400).json({ error: 'Idempotency-Key header required' });

const existing = await db.idempotencyKeys.findOne({ key: idempotencyKey });
  if (existing) return res.status(existing.statusCode).json(existing.responseBody);

const result = await chargeCard(req.body);

await db.idempotencyKeys.insertOne({
    key: idempotencyKey,
    statusCode: 200,
    responseBody: result,
    createdAt: new Date(), // TTL-indexed so old keys eventually expire
  });
  res.json(result);
});
```
The tricky part is the race between two identical requests arriving concurrently before either finishes — a unique index on the idempotency key (so the second insert conflicts rather than both proceeding) or a short-lived distributed lock around the check-then-act sequence is needed to close that window.

Question 33

How does DataLoader solve the N+1 problem in a GraphQL Node.js server?

Accepted Answer

A GraphQL resolver for a field like Post.author runs once per post in the result set — if a query returns 50 posts and each author resolver independently queries the database, you've just issued 50 separate queries (the N+1 problem: 1 for posts, N for their authors) where a single batched query would do.

DataLoader fixes this by batching and caching within a single request/tick: instead of resolvers calling the database directly, they call loader.load(id), which doesn't hit the database immediately — DataLoader collects every .load() call made during the current tick, then fires one batched function with all collected IDs.
```js
const DataLoader = require('dataloader');

const resolvers = {
  Post: {
    author: (post) => authorLoader.load(post.authorId), // batched automatically
  },
};
```
The loader must be created fresh per-request (usually in the GraphQL context factory), not as a shared singleton — a request-scoped loader also gives free per-request caching without risking stale data leaking across different users' requests.

Question 34

Explain distributed locks using Redis (Redlock) — when would you actually need one?

Accepted Answer

A regular in-process mutex only protects against concurrent access within one process — it does nothing once you have multiple Node instances, which is the normal case for any horizontally-scaled service. A distributed lock solves the equivalent problem across processes/machines: e.g. a scheduled job that must run on exactly one instance despite being deployed on 5 replicas, or preventing two concurrent requests on different servers from both processing the same queued item.

Redlock is built on Redis's SET key value NX PX ttl — set a key only if it doesn't already exist, with an expiry — so the first process to succeed 'holds the lock', and any other attempt fails until the key expires or is released:
```js
const Redlock = require('redlock');
const redlock = new Redlock([redisClient], { retryCount: 3 });

async function runNightlyReconciliation() {
  let lock;
  try {
    lock = await redlock.acquire(['locks:nightly-reconciliation'], 60_000);
    await doReconciliationWork();
  } catch (err) {
    if (err.name === 'LockError') return; // another instance already has it
    throw err;
  } finally {
    if (lock) await lock.release();
  }
}
```
The real Redlock algorithm acquires the lock across multiple independent Redis nodes and requires a majority, specifically to survive a single node failing mid-lock — a single-instance Redis lock is fine for most non-critical cases like the job above, but for something where double-execution would be genuinely dangerous, the multi-node algorithm or a database-backed SELECT ... FOR UPDATE lock is the more defensible choice.

Question 35

What's the difference between .pipe() and stream.pipeline() when it comes to handling errors in Node streams?

Accepted Answer

.pipe() connects a readable to a writable and forwards data automatically, but deliberately does not forward errors or handle cleanup — if the source errors, the destination isn't automatically closed, and you have to attach your own error listeners to every stream in the chain, or risk an unhandled error crashing the process or silently leaking file descriptors/sockets.

stream.pipeline() was added specifically to fix this: it pipes a series of streams together and guarantees that if any stream in the chain errors or is closed, every other stream gets destroyed and cleaned up, surfacing a single callback/Promise result instead of requiring separate listeners on each stream.
```js
// .pipe() — error on src leaves dest open, callers must remember error listeners on both
src.pipe(dest);
src.on('error', handleError);
dest.on('error', handleError); // dest is NOT auto-closed just because src errored

// pipeline() — one call, automatic cleanup of every stream on any failure
const { pipeline } = require('stream/promises');
try {
  await pipeline(src, transform, dest);
} catch (err) {
  // guaranteed: src, transform, and dest are all already destroyed here
}
```
This is why pipeline() (or the promise-based stream/promises variant) is the recommended default in modern Node code, and .pipe() mostly shows up in older codebases or simple cases where every stream's error is handled explicitly.

Question 36

How do you propagate a correlation/request ID across microservice calls in Node for tracing?

Accepted Answer

When a single user action fans out across multiple services (gateway → auth → orders → payment), debugging a failure means correlating log lines across all of them — impossible unless every service tags its logs with the same shared identifier for that one logical request. A correlation ID is generated once at the edge and passed along on every downstream call, then included in every log line each service emits.

Node's AsyncLocalStorage is the modern way to carry this ID through a request's entire async call chain without manually threading it through every function signature:
```js
const { AsyncLocalStorage } = require('async_hooks');
const als = new AsyncLocalStorage();

app.use((req, res, next) => {
  const requestId = req.headers['x-request-id'] || crypto.randomUUID();
  res.setHeader('x-request-id', requestId);
  als.run({ requestId }, next); // requestId now available anywhere down this request's call chain
});

function logger(msg) {
  const store = als.getStore();
  console.log(JSON.stringify({ requestId: store?.requestId, msg }));
}

async function callOrdersService(req) {
  const { requestId } = als.getStore();
  return fetch('http://orders-svc/internal', { headers: { 'x-request-id': requestId } });
}
```
For real production tracing (not just log correlation), this is usually done via OpenTelemetry, which auto-instruments common HTTP clients/servers and propagates trace context using the W3C traceparent header — giving a proper distributed trace with per-hop timing, not just a shared string to grep logs for.

Question 37

How do you implement structured logging in Node (e.g., with pino) instead of console.log, and why does it matter at scale?

Accepted Answer

console.log produces unstructured free-text lines — fine for local debugging, but painful at scale: you can't reliably filter, aggregate, or alert on 'all 500 errors for user X in the last hour' from plain text without fragile regex parsing, and every service tends to format messages slightly differently. Structured logging emits each line as a JSON object with consistent fields (timestamp, level, message, arbitrary context), which log aggregators (Datadog, CloudWatch, ELK) can index and query directly.

```js
const pino = require('pino');
const logger = pino({ level: process.env.LOG_LEVEL || 'info' });

app.use((req, res, next) => {
  req.log = logger.child({ requestId: req.headers['x-request-id'] }); // context on every log this request emits
  next();
});

app.post('/orders', (req, res) => {
  req.log.info({ userId: req.user.id, itemCount: req.body.items.length }, 'order created');
});
```
pino specifically is popular in Node because it's built for minimal overhead — it does JSON serialization as fast as possible and defers pretty-printing to a separate transform used only in development, so production doesn't pay a formatting cost per log line. At scale, structured fields let you alert on things plain text can't — e.g. 'p99 of durationMs exceeds 2s, grouped by route' directly from your logging platform's query language.

Question 38

What is a memory leak in Node.js, and what are the most common causes?

Accepted Answer

A memory leak happens when your application keeps holding references to objects it no longer needs, preventing the garbage collector from ever reclaiming that memory — RSS/heap usage climbs steadily over time, rather than sawtoothing up and down as GC normally does its job, until the process eventually OOMs or gets killed by its orchestrator.

Common causes in real Node services: global caches or Maps that grow unbounded; forgotten EventEmitter listeners that accumulate closures from short-lived requests/connections; closures retaining large data structures longer than intended (e.g. a setInterval callback that closes over a big object and is never cleared); module-level arrays used as makeshift queues that get pushed to but never drained.
```js
// classic unbounded-cache leak
const cache = new Map();
app.get('/user/:id', async (req, res) => {
  if (!cache.has(req.params.id)) {
    cache.set(req.params.id, await db.users.findById(req.params.id)); // never evicted, grows forever
  }
  res.json(cache.get(req.params.id));
});
// fix: use an LRU cache with a max size (e.g. lru-cache) or a TTL
```
The fix is almost always the same shape: whatever adds an entry to a long-lived collection needs a matching removal path — the bug is rarely 'the GC is broken', it's that something in your own code is still holding a reference the GC has to respect.

Question 39

How do you use --max-old-space-size and heap snapshots to debug a memory leak in a Node service?

Accepted Answer

--max-old-space-size sets V8's heap size limit in MB — raising it doesn't fix a leak, it just delays the crash, but it's a useful diagnostic lever: if raising the limit just pushes the OOM further out on the same growth curve, you've confirmed a genuine leak rather than a one-time large allocation.

Heap snapshots are the actual diagnostic tool: they capture the full graph of live objects, letting you inspect which objects consume the most memory and, critically, what's still holding a reference to them — that retainer chain tells you why something wasn't garbage collected.
```js
const v8 = require('v8');
const fs = require('fs');

process.on('SIGUSR2', () => {
  const filename = `heap-${Date.now()}.heapsnapshot`;
  fs.writeFileSync(filename, JSON.stringify(v8.getHeapSnapshot()));
});
```
```bash
node --max-old-space-size=4096 --inspect app.js  # raise limit + expose inspector for Chrome DevTools
```
The practical workflow: take two snapshots several minutes apart under sustained load, load both into Chrome DevTools' Memory tab, and use its comparison view — it shows exactly which object types grew between the snapshots and lets you drill into retainer paths, which almost always leads straight to the specific Map/array/listener array that's the culprit.

Question 40

Cursor-based pagination vs offset pagination in a Node API — why is cursor preferred at scale?

Accepted Answer

Offset pagination (LIMIT 20 OFFSET 1000) asks the database to skip past the first 1000 rows every time — the database still has to scan/count through those skipped rows internally, so later pages get progressively slower as the offset grows. It also has a correctness bug under concurrent writes: if a row is inserted or deleted between two page requests, offset pagination can skip a row entirely or show the same row twice, because 'offset 20' refers to a different set of rows once the underlying data has shifted.

Cursor-based pagination uses a stable, ordered field (usually the primary key or a createdAt+id tuple) from the last item on the previous page as the starting point for the next query — the database jumps straight there using an index instead of scanning past skipped rows, and stays correct under concurrent inserts/deletes.
```js
// offset — gets slower as page number grows, and can skip/duplicate rows
const page5 = await db.query('SELECT * FROM posts ORDER BY id LIMIT 20 OFFSET 80');

// cursor — constant-time regardless of how deep you page, stable under concurrent writes
const nextPage = await db.query(
  'SELECT * FROM posts WHERE id > $1 ORDER BY id LIMIT 20',
  [lastSeenId]
);
```
The trade-off is that cursor pagination can't jump directly to an arbitrary page number the way offset can — which is why offset is still fine for small, rarely-changing datasets or admin UIs needing page-number jumping, while cursor pagination is the right default for large, high-throughput, or infinite-scroll APIs.

Question 41

How does Node's single-threaded event loop model affect horizontal vs vertical scaling decisions for an API?

Accepted Answer

Node runs your JS on one thread, so a single process can only use one CPU core no matter how many the machine has — throwing a bigger machine at a Node app gives more RAM and I/O capacity, but doesn't let a single process do more CPU-bound work in parallel, since only one thread executes your code at a time (I/O concurrency remains excellent, since that's handled by libuv/the OS, not the main thread).

This is why Node scales primarily horizontally by convention — running multiple independent processes (via cluster, PM2 cluster mode, or simply multiple container replicas behind a load balancer) so each core/instance handles more concurrent connections and aggregate CPU work:
```js
const cluster = require('cluster');
const numCPUs = require('os').cpus().length;

if (cluster.isPrimary) {
  for (let i = 0; i < numCPUs; i++) cluster.fork(); // one process per core
  cluster.on('exit', () => cluster.fork()); // auto-restart crashed workers
} else {
  require('./server').listen(3000);
}
```
In practice real systems combine both: vertical scaling still helps (more RAM per instance means larger connection pools/caches), but the ceiling on raw compute always comes down to running more Node processes — whether via cluster on one bigger box or more replicas across many smaller ones, the latter also giving resilience a single machine doesn't.

Question 42

What are sticky sessions, and why do they matter for WebSocket connections behind a load balancer with multiple Node instances?

Accepted Answer

A WebSocket connection is a single, long-lived TCP connection between one client and one specific server process — unlike stateless HTTP requests, it can't be transparently handled by a different backend instance later, because there is no 'next request'; it's one continuous connection. The problem shows up when the app also relies on regular HTTP requests from the same client landing on the same instance holding their WebSocket connection — e.g. an HTTP endpoint that looks up 'the in-memory socket for this user' to push a message.

Sticky sessions (session affinity) configure the load balancer to route all requests from the same client consistently to the same backend instance, keeping that in-memory socket reachable:
```nginx
upstream node_backend {
    ip_hash;  # requests from the same client IP always route to the same upstream server
    server node1:3000;
    server node2:3000;
    server node3:3000;
}
```
Sticky sessions solve routing but not the underlying scaling problem — if that instance restarts, in-memory-only state is lost. The more robust fix (used with or instead of stickiness) is backing the socket registry with Redis pub/sub so any instance can push a message to any connected client regardless of which instance physically holds that socket, removing the hard requirement on affinity altogether.

Question 43

What is the purpose of putting a reverse proxy like Nginx in front of a Node.js app?

Accepted Answer

Node's built-in HTTP server is capable, but a reverse proxy handles several concerns better and cheaper than reimplementing them in application code: TLS termination (Nginx handles the SSL/TLS handshake once, so Node only deals with plain HTTP internally), serving static assets directly from disk (much faster than Node streaming a file per request), request buffering/compression, and load balancing across multiple Node instances on the same host.

```nginx
server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate /etc/ssl/cert.pem;
    ssl_certificate_key /etc/ssl/key.pem;

location /static/ {
        root /var/www;               # served directly by Nginx, never touches Node
        expires 30d;
    }

location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
```
It also buffers against slow clients — Nginx can fully buffer a slow-uploading request before handing it to your app, so a single-threaded Node process isn't left holding that connection open itself. In Kubernetes environments this role is often played by an Ingress controller (usually Nginx or Envoy under the hood) rather than a hand-configured box, but the underlying purpose is the same.

Question 44

How does database connection pooling work in Node, and why shouldn't you create a new pool per request?

Accepted Answer

Opening a new database connection is expensive relative to running a query — it involves a TCP handshake, often a TLS handshake, and authentication, all before your query even runs. A connection pool solves this by opening a modest number of connections once, up front, handing them to your code on demand — when a query finishes, the connection returns to the pool for reuse rather than closing, so subsequent queries skip the connection-setup cost entirely.

```js
const { Pool } = require('pg');
const pool = new Pool({ max: 10, idleTimeoutMillis: 30_000 }); // created ONCE, at module load

app.get('/users/:id', async (req, res) => {
  const { rows } = await pool.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
  res.json(rows[0]);
});
```
Creating a new Pool() (or a fresh raw connection) inside a request handler defeats the point — every request pays the full connection-setup cost, and worse, if you don't explicitly close it, each request leaks a new pool that's never returned, exactly how you exhaust the database's max-connections limit under real traffic. The pool should be a singleton created once at startup (or reused across warm serverless invocations) and imported wherever queries are needed, never instantiated per-request.

Question 45

REST vs gRPC for inter-service communication in a Node microservices architecture — what are the trade-offs?

Accepted Answer

REST over HTTP/JSON is what most public APIs use — human-readable, easy to debug with curl/Postman, universally supported, but JSON serialization has real CPU/bandwidth overhead, and REST doesn't define a strict contract, so services can drift out of sync without a shared schema unless you bolt one on (OpenAPI). gRPC uses Protocol Buffers (a compact binary format) over HTTP/2, generates strongly-typed client/server code from a .proto schema, and supports native streaming (client, server, and bidirectional), which REST has no first-class equivalent for.

```proto
service OrderService {
  rpc GetOrder (OrderRequest) returns (OrderResponse);
}
message OrderRequest { string orderId = 1; }
message OrderResponse { string orderId = 1; double total = 2; string status = 3; }
```
```js
const client = new orderProto.OrderService('orders-svc:50051', grpc.credentials.createInsecure());
client.getOrder({ orderId: '123' }, (err, response) => console.log(response.status));
```
In practice: gRPC is stronger for internal service-to-service calls where performance matters and you want the schema as the actual source of truth (a breaking .proto field change is a compile error for consumers, not a silent runtime surprise); REST/JSON remains right for public-facing APIs, browser clients (browsers can't easily consume raw gRPC without a proxy like grpc-web), and anywhere plain-HTTP debuggability matters more than raw throughput.

Question 46

How does helmet.js secure an Express app, and what does it actually set on responses?

Accepted Answer

helmet isn't a single security feature — it's a collection of small middleware functions that each set one HTTP response header known to mitigate a specific class of browser-side attack, bundled together for convenience. Without it, an Express app by default sends none of these protective headers, leaving clients exposed to attacks the browser itself would otherwise block if told to.

```js
const helmet = require('helmet');
app.use(helmet()); // applies sane defaults; each piece can also be configured individually

app.use(helmet.contentSecurityPolicy({
  directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'", 'trusted-cdn.com'] },
}));
```
Concretely, the defaults include Strict-Transport-Security (forces browsers to only use HTTPS for your domain), X-Content-Type-Options: nosniff (stops browsers from guessing/overriding a response's declared MIME type, historically enabling certain XSS vectors), X-Frame-Options/frame-ancestors (prevents pages being embedded in a malicious iframe for clickjacking), and it removes X-Powered-By: Express, which otherwise tells an attacker exactly which framework/version to target.

helmet() is a low-effort, high-value addition — a handful of headers, not a replacement for input validation, auth, or rate limiting, but it closes off several well-known browser-level attack classes essentially for free.

Question 47

What's the difference between authentication and authorization, and how do you implement role-based access control (RBAC) middleware in Express?

Accepted Answer

Authentication answers 'who are you' — verifying identity, usually via a password check, JWT verification, or session lookup. Authorization answers 'what are you allowed to do' — given a known identity, deciding whether a specific action is permitted. Conflating the two is a common bug source: an endpoint that only checks 'is this a valid logged-in user' but never checks 'is this user allowed to delete this resource' is how one user ends up modifying another user's data.

RBAC implements authorization by attaching a role to the authenticated user and gating routes behind a middleware that checks it:
```js
function requireRole(...allowedRoles) {
  return (req, res, next) => {
    if (!req.user) return res.status(401).json({ error: 'not authenticated' }); // authentication check
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({ error: 'forbidden' }); // authorization check — distinct failure mode
    }
    next();
  };
}

app.delete('/admin/users/:id', authenticate, requireRole('admin'), deleteUserHandler);
```
Note the distinction between 401 (not authenticated — go log in) and 403 (authenticated but not permitted) — returning the wrong code is a small but real bug, since clients often use it to decide whether to redirect to login versus show a permissions error. Pure role checks also aren't always enough — 'can this user delete order #123' often additionally needs a resource-ownership check, which RBAC alone doesn't cover without an extra per-resource check.

Question 48

How can Node's single-threaded event loop handle thousands of concurrent connections?

Accepted Answer

'Single-threaded' refers only to where your JavaScript executes — it doesn't mean Node does everything on one thread. Network I/O (accepting connections, reading/writing sockets) is handled by the OS's asynchronous I/O facilities (epoll on Linux, kqueue on macOS, IOCP on Windows), extremely efficient at monitoring thousands of file descriptors simultaneously without dedicating a thread to each. Node's event loop asks the OS to report when any of these sockets has new data, and runs the relevant JS callback one at a time, each typically doing a tiny amount of work before yielding back.

The model works well because most web server work is I/O-bound: a request handler spends most of its wall-clock time waiting — for a database round-trip, an external API call — during which the single JS thread is completely free to process other requests' callbacks. Contrast this with a thread-per-connection model, which handles that same waiting time by literally blocking a whole OS thread per connection — fine for a handful of connections, but thread memory overhead (~1-2MB stack per thread) and context-switching cost make thousands of concurrently-blocked threads far more expensive than thousands of lightweight callback registrations.
```js
app.get('/slow-io', async (req, res) => {
  const data = await db.query('SELECT pg_sleep(2), * FROM big_table'); // thread is free during this wait
  res.json(data);
});
```
This model breaks down specifically for CPU-bound work (a tight synchronous loop, synchronous crypto/compression) since that genuinely occupies the one JS thread and blocks every other pending callback — exactly the class of problem worker_threads exists to solve.

Question 49

What's the difference between npm ci and npm install, and why should CI pipelines use npm ci?

Accepted Answer

npm install reads package.json, resolves the dependency tree (potentially updating package-lock.json if versions have drifted or a new package was added), and can install slightly different versions across machines/times if the lockfile and package.json don't perfectly agree — designed for active development where you're adding/updating packages. npm ci ('clean install') requires an existing package-lock.json, installs exactly what it specifies with no resolution or updates, and fails outright if package.json and the lockfile are out of sync, rather than silently reconciling them.

```bash
# npm install: may modify package-lock.json, tolerant of drift, slower (has to resolve)
npm install

# npm ci: exact, reproducible install from the lockfile; deletes node_modules first; fails fast on drift
npm ci
```
For CI/CD, npm ci is preferred for three concrete reasons: it's meaningfully faster (skips dependency resolution since the lockfile is already fully resolved), it guarantees the exact dependency tree tested locally/in a PR actually gets deployed (no transitive dependency resolving differently in CI), and it fails loudly if someone forgot to commit an updated lockfile after changing package.json, catching a real bug before it reaches production rather than silently papering over it.

Question 50

Token bucket vs sliding window rate limiting — how do they differ and what are the trade-offs for a Node API?

Accepted Answer

Both limit how many requests a client can make in a given period, but model 'the limit' differently. A token bucket holds a fixed capacity of tokens that refill at a steady rate; each request consumes one token, and requests are rejected once the bucket is empty — this naturally allows short bursts (as long as tokens have accumulated) while still enforcing a steady-state average rate, matching how real traffic behaves (bursty, not smooth). A sliding window counts how many requests occurred within the last N seconds relative to right now (continuously moving, not reset on a fixed boundary), giving a smoother, more precise limit than a naive fixed window but without token bucket's deliberate burst allowance.

The naive fixed window has a real edge-case bug worth knowing: a limit of '100 requests per minute' measured in fixed clock-minute buckets lets a client send 100 requests at 0:59 and another 100 at 1:01 — 200 requests in 2 seconds, technically compliant with both windows individually. Sliding window fixes this by always looking back a full window from the current moment rather than snapping to a clock boundary.
```js
const { RateLimiterRedis } = require('rate-limiter-flexible');
const limiter = new RateLimiterRedis({
  storeClient: redisClient,
  points: 100,      // bucket capacity — 100 tokens
  duration: 60,     // refills fully over 60s
});

await limiter.consume(userId); // throws if the bucket has no tokens left — allows bursts up to capacity
```
Token bucket is generally preferred for user-facing APIs since legitimate usage is naturally bursty and you don't want to punish that; sliding window is preferred when you need a hard, precise cap with no burst allowance — e.g. protecting a downstream system that genuinely cannot handle more than X requests in any rolling period.

Question 51

What is Node.js, and why is it commonly used for building backend APIs?

Accepted Answer

Node.js is a JavaScript runtime built on Chrome's V8 engine that lets you run JavaScript outside the browser — on a server. Before Node existed, JavaScript only ran in browsers; Node made it possible to write the backend of a web app in the same language as the frontend, so a team can share code, types, and skills across both sides of an application.

The main reason Node is popular for backend APIs is its non-blocking, event-driven I/O model. Instead of creating a new thread for every incoming request (which is expensive in memory and CPU), Node runs on a single main thread and hands off slow work — reading a file, querying a database, calling another API — to the underlying system, continuing to handle other requests while it waits for a response. This makes Node very efficient for I/O-heavy workloads like REST APIs, where a server mostly waits on databases and network calls rather than doing heavy computation.

A simple example that shows this non-blocking behavior:
```js
const http = require('http');

http.createServer((req, res) => {
  // Simulate a slow database call without blocking other requests
  setTimeout(() => {
    res.end('Response after 2 seconds');
  }, 2000);
}).listen(3000);

console.log('Server is running on port 3000');
```
Even while one request is 'waiting' inside that setTimeout, the server is still free to accept and start handling other incoming requests at the same time — it isn't stuck doing nothing until the timer finishes. In practice, most real Node backends use a framework like Express on top of this to make routing and handling requests easier, but the underlying reason Node scales well for APIs is this single-threaded, non-blocking design.

Question 52

What's the difference between the GET and POST HTTP methods, and when would you use each when building a Node.js/Express API?

Accepted Answer

GET and POST are two of the most common HTTP methods, and they're used for fundamentally different purposes. GET is meant for retrieving data — you use it when the client just wants to read something from the server, like fetching a user's profile or a list of products. A GET request normally has no request body, and any input it needs (like a search term or an ID) is passed through the URL itself, either as a route parameter or a query string.

POST is meant for sending data to the server to create something or trigger an action with side effects, like signing up a new user or submitting a form. Unlike GET, a POST request carries its data in the request body, which can hold much more information (including files, nested objects, etc.) than a URL comfortably can. Another important difference: GET requests are idempotent and safe to cache or repeat (fetching the same product twice doesn't change anything on the server), while POST requests are not idempotent — submitting the same POST twice can create two separate records, which is why browsers warn you before resubmitting a form.

Here's how the two look in an Express app:
```js
const express = require('express');
const app = express();
app.use(express.json());

// GET: read data, input comes from the URL (route param here)
app.get('/users/:id', (req, res) => {
  const userId = req.params.id;
  res.json({ id: userId, name: 'Jane Doe' });
});

// POST: create data, input comes from the request body
app.post('/users', (req, res) => {
  const { name, email } = req.body;
  const newUser = { id: Date.now(), name, email };
  res.status(201).json(newUser);
});
```
As a simple rule of thumb: if the request is just asking to view or fetch something, use GET; if it's asking the server to create, change, or process something, use POST (or one of its relatives like PUT/PATCH/DELETE for updates and removals).

Backend (Node.js) Interview Questions & Answers

Ready to practice these live?