Node.js Performance Tips: From 100 to 10,000 Requests Per Second (+ Interview Questions)

• "When would you skip compression for a route?" Skip it for already-compressed payloads (images, videos, zipped files) and for tiny responses - the compression overhead can exceed the bytes saved. compression() has a threshold option (default 1KB) for exactly this reason.
• "Does compression happen on the event loop?" Yes - zlib's synchronous compression runs on the main thread by default for small payloads, though Node's zlib module can offload larger jobs. This is why compression is cheap per-request but not free at extreme request volume.
• "How would you verify compression is actually working?" Check the Content-Encoding: gzip response header, or compare payload size with curl -H "Accept-Encoding: gzip" -o /dev/null -w "%{size_download}\n" <url> against an uncompressed request.

• "Do cluster workers share memory?" No - each worker is a separate OS process with its own heap and event loop. Anything that needs to be shared across workers (sessions, rate-limit counters, caches) has to live externally, typically in Redis.
• "When would you reach for worker threads instead of cluster?" Cluster scales concurrent I/O-bound requests across cores. Worker threads solve a different problem - offloading a single CPU-heavy task (image processing, hashing) off the main thread without blocking it, and they can share memory via SharedArrayBuffer.
• "How do you run cluster mode in production without hand-rolling it?" Most teams reach for a process manager instead: pm2 start server.js -i max clusters across all cores and handles restarts, without you writing the fork logic yourself.

• "How do you pick the max pool size?" It's bounded by the database's connection limit divided across every app instance, not by how much load you're handling - a pool of 20 per instance times 10 clustered workers is already 200 connections. Start conservative and watch for pool-exhaustion errors under load.
• "What happens when every connection in the pool is busy?" The next pool.query() call queues until a connection frees up or connectionTimeoutMillis is hit, at which point it rejects. That's a deliberate backpressure valve, not a bug.
• "Is connection pooling only relevant to SQL databases?" No - MongoDB drivers, Redis clients, and HTTP keep-alive agents all pool connections for the same reason: avoiding repeated handshake cost per request.

• "How would you confirm a memory leak in production without SSH-ing into the box?" Expose process.memoryUsage().rss on a metrics endpoint or dashboard and watch the trend over hours, not seconds - a leak shows up as a line that never comes back down after garbage collection, not as a spike.
• "What's the difference between a memory leak and normal memory growth?" Normal growth plateaus as the garbage collector reclaims unused objects between requests. A leak keeps climbing indefinitely because something external to the GC - a live reference - is holding objects hostage.
• "Name three code patterns that commonly cause leaks." Event listeners added per-request without removal, unbounded caches or arrays that grow forever, and timers (setInterval) that are never cleared when the thing they're tracking goes away.

• "How do you spot an N+1 query in a code review?" Look for a database call sitting inside a .map(), .forEach(), or for loop that iterates over a previous query's results - that shape is the tell, regardless of the ORM.
• "Is a join always the right fix?" Usually, but not always - if you're using an ORM, batching with a DataLoader-style pattern (collect IDs, fire one IN (...) query, map results back) avoids a join when the relationship is more complex than SQL handles cleanly.
• "Would an ORM like Prisma or Sequelize prevent this automatically?" No - most ORMs will happily generate N+1 queries unless you explicitly ask for eager loading (include in Prisma, .populate() in Mongoose). The ORM doesn't know your access pattern; you have to tell it.

• "Why measure before optimizing instead of just applying known best practices?" Because the "known best practice" might not be your bottleneck - a CPU-bound synchronous loop won't be fixed by connection pooling, and applying it anyway burns time without moving the metric that matters.
• "What's the difference between throughput and latency, and why do you need both?" Throughput (req/sec) tells you total capacity; latency percentiles (p50, p99) tell you the experience of an individual request. A change can raise throughput while making tail latency worse for unlucky requests - you need both numbers to know if a fix actually helped.
• "What would you check if autocannon shows high latency but low CPU usage?" That pattern usually points away from compute and toward I/O wait - an unpooled database connection, a slow downstream API call, or event loop lag from a blocking operation. Check perf_hooks' monitorEventLoopDelay next.

• "Where would you add a cache, and what would you use?" In front of expensive, frequently-read, rarely-changing data - an in-process LRU cache (lru-cache) for ultra-hot single-instance reads, and Redis for anything that needs to be shared across clustered workers or multiple app instances.
• "How do you avoid serving stale data from a cache?" Set a TTL matched to how often the underlying data actually changes, and invalidate explicitly on writes rather than relying on TTL alone for anything user-facing (e.g., delete the cache key right after an update, don't wait for expiry).

Event loop health

• "How do you detect event loop lag before users notice it?" perf_hooks' monitorEventLoopDelay() tracks how long the loop is delayed between iterations; alert when the mean delay crosses a threshold like 50-100ms, since that's roughly where users start perceiving slowness.
• "What's a common cause of event loop blocking that isn't an obvious infinite loop?" Synchronous JSON parsing or stringifying of a large payload, synchronous crypto (crypto.pbkdf2Sync), and array methods run over very large in-memory datasets - all of these look like normal code but hold the thread for milliseconds to seconds.

HTTP and networking

• "What does HTTP keep-alive do for throughput?" It reuses an existing TCP connection across multiple requests instead of renegotiating a handshake each time - Node's default HTTP agent enables this, but outbound calls to other services need keepAlive: true set explicitly on the agent to benefit.
• "How does HTTP/2 change performance characteristics versus HTTP/1.1?" HTTP/2 multiplexes many requests over a single connection, removing the six-connections-per-origin limit browsers impose on HTTP/1.1 - which matters most for APIs serving many small resources to the same client.

Process and deployment

• "How do you deploy a performance fix without dropping in-flight requests?" Pair clustering with graceful shutdown - stop accepting new connections on SIGTERM, let in-flight requests finish, then exit - and roll workers one at a time (pm2 reload) instead of restarting all of them simultaneously.
• "If req/sec looks fine locally but drops under production load, what do you check first?" Whatever differs between the two environments: connection pool size against the real database's connection limit, whether clustering is actually enabled in the production process manager config, and network latency to a database or cache that's co-located in dev but remote in production.