Node.js interview questions: Performance and observability

I'd say event-loop lag, or event-loop delay, same thing. Node runs your JavaScript on a single thread, so if anything blocks the event loop, every request gets delayed, and the thing is CPU and memory can still look totally fine while that's happening. So watching the lag tells you when the loop is falling behind. You measure it with perf_hooks, there's a monitorEventLoopDelay function that records the delay into a histogram. If the lag is rising it means the loop can't get to events promptly, usually because of synchronous or CPU-heavy work somewhere. You'd set an alert threshold, maybe tens of milliseconds or something like that, and investigate when it crosses. The usual fix is moving the blocking work off the main thread, into a worker thread or an async operation. It catches problems the CPU and memory graphs just miss, so it's the one to watch first.

I'd start with process.memoryUsage() and look at which number is actually growing. RSS is the total resident memory the process is holding. heapUsed is how much of the V8 heap is in use, and external is memory from C++ objects bound to JavaScript, Buffers mostly. If heapUsed keeps growing it's probably a JavaScript leak, objects being retained that should have been collected. So I'd take heap snapshots at intervals and compare them in Chrome DevTools to see what's piling up. Usual suspects are unbounded caches, event listeners nobody removed, closures holding references, that kind of thing. If it's external that's growing, that points at Buffers or native memory instead. Basically look at what allocates over time and whether the references ever get released, then fix whatever code is holding them. Restarting just masks it, so the goal is finding the actual retention.

So V8's garbage collector is generational. Most objects die young and get collected quickly in the young generation by minor GCs, which are fast. Objects that survive get promoted to the old generation, and that gets collected by major GCs, which are more expensive and can pause the process. And since Node runs your JavaScript on one thread and GC runs on that same thread, a long major GC blocks your request callbacks, which is basically the latency spike you're seeing. To cut the impact you want to make less garbage. Avoid allocations you don't need, reuse buffers and objects, drop references you're done with. There are flags like --max-old-space-size to tune the heap, but that's kind of a blunt tool. Lowering allocation pressure is usually the better move, since GC then runs less often and has less to do. --trace-gc or performance hooks tell you how much time actually goes to collection.

Averages hide the tail, basically. If most requests are fast but some small fraction are really slow, the average still looks fine while those users are having a terrible time. p99 is the value that 99% of requests come in under, so it captures that slow tail, the worst case real users actually hit. That's why people watch percentiles like p95, p99, p99.9 instead of the mean. And to compute percentiles correctly you need the distribution of latencies, which is what histograms give you. They bucket the response times so you can calculate percentiles and aggregate across servers. A single average per server can't really be combined in any meaningful way. The tail matters too because in systems making lots of calls, the slow ones end up dominating the overall response time. So you track latency as a histogram and watch the high percentiles, and those tell you what your slowest users are experiencing.

There's a bunch of ways a load test can trick you. First, warm up before you measure, because the first requests hit cold caches and code that hasn't been optimized yet, so the early numbers don't represent steady state. You want realistic traffic patterns and payloads too, not some trivial endpoint. Then there's coordinated omission, where the tool waits for a slow response before sending the next request. That hides the true tail latency since the delayed requests never get counted, so you use tools that account for it. There's also open versus closed models, open means requests arrive at a fixed rate regardless of responses, closed means a fixed number of clients each wait for a response. Open is closer to real traffic, I think. Report percentiles since averages hide the tail, find the point where the service degrades, and test somewhere close to production so the results transfer.

A cache makes sense when reads happen a lot, the data's expensive to fetch, and it doesn't change too often. The main decision is where to put it. An in-process cache is fastest because it's just memory in the same process, but each instance keeps its own copy, so instances can disagree. Something shared like Redis stays consistent across instances and holds more, but you pay a network hop. You set a TTL so entries expire, and you still need an invalidation plan for when data changes. The known problem is a cache stampede, where a popular item expires and a bunch of requests all recompute it at once and overload the backend. You prevent that with a lock so only one request recomputes, or by refreshing before expiry. And you watch the hit rate to confirm it's doing its job. Really it depends on your consistency and performance needs.

So tracing works by giving each request a trace ID and carrying that ID through all the work done for it, including across service calls in headers. The tricky part inside a Node process is that the work happens across async callbacks, so a normal local variable doesn't survive. Node has AsyncLocalStorage, which stores data that stays associated with the current asynchronous execution context, so any code running as part of that request can read the trace context without passing it around explicitly. Under the hood it uses async_hooks to track async operations, I believe, and that tracking adds overhead to every async operation, so tracing isn't free. Turning it on can measurably slow the app down. That's why you sample, only tracing a fraction of requests. And between services the trace context travels in HTTP headers, there's a standard, W3C Trace Context, so the trace continues in the next service.

At scale logging becomes a performance and cost thing. Structured logging means emitting logs as JSON with fields instead of plain strings, which matters because you can query and filter by field in your log aggregation system, and you need that once the volume gets big. Plain string logs are hard to search and parse. Logging itself isn't free either, serializing objects and writing them costs CPU, and if the writes are synchronous or the destination is slow, it can block the event loop. Pino is the popular fast logger for Node. It does minimal work on the main thread, produces the JSON efficiently, and can push the writing and processing off to a separate transport or worker so it doesn't slow down request handling. At high volume you also sample, keep a fraction of the noisy high-frequency logs to control cost but keep the errors. So you get visibility without logging becoming the bottleneck.

Start by measuring what one instance can handle. A Node process runs your JavaScript on one thread, so one process uses roughly one CPU core for request work, and on a multi-core machine you run several processes with the cluster module, or several containers, to cover all the cores. Then you load test one instance to find how many requests per second it sustains inside your latency target. Divide expected peak traffic by that number, add some safety margin, and that's your instance count. You monitor CPU, event-loop lag, and latency so you know when you're near capacity. Whether to scale out or optimize depends on the bottleneck, I'd say. If CPU is spread across lots of requests, more instances help. If it's a single slow function or a blocked event loop, fixing the code is better. And scaling out costs money continuously while optimizing is a one-time effort, so you weigh those.