Node.js interview questions: Errors and reliability

So if a promise rejects and nothing handles it, older versions of Node just printed a deprecation warning, but modern Node treats it as fatal and crashes the process. Which is why you always attach a .catch or wrap your await in a try/catch. Most teams I've seen also register process.on('unhandledRejection') and process.on('uncaughtException') handlers so they can log the error and report it to monitoring before anything gets lost. The usual advice is basically log it with the stack trace, send it to your error tracker, and if it looks serious, shut down gracefully, because one bad request shouldn't take down the whole service. And your process manager or orchestrator restarts the app for you anyway, so really the main job is making sure every rejection either gets handled locally or gets caught by a global handler somewhere.

So operational errors are the failures you kind of expect even when your code is correct. A network timeout, a refused connection, a missing file, a 503 from some downstream service. Your program anticipates those and does something about them, retries, returns an error to the client, falls back to a default. Programmer errors are just bugs. Reading a property of undefined, passing the wrong type, calling an API the wrong way. You can't really handle a bug at runtime, so the standard advice is let the process crash, restart it under a supervisor, and go fix the code. In practice I think teams usually define custom error classes with a flag like isOperational, handle the operational ones close to where they happen, and let everything else propagate up to a top-level handler that logs and exits. The whole point of the distinction is you don't have to wrap every line in a defensive try/catch.

So 'error' is the one event name that EventEmitter treats specially. For any other event, emitting with zero listeners is just a no-op, nothing happens. But if an emitter emits 'error' and nothing is listening, Node throws the error and the process crashes with that Unhandled 'error' event message. Which is why the standard advice is to always attach an 'error' listener to streams, sockets, servers, basically any emitter that can fail. I think the reason these objects report failures as events rather than exceptions or rejections is that the failure happens later, after the original call has already returned, so there's nothing to throw into. Once a listener is attached the error gets delivered like any other event and the process keeps running, and a typical handler just logs the error and cleans up the resource.

So the basic idea is you listen for SIGTERM, stop taking new work, let whatever's in flight finish, release your resources, and exit. Concretely you register a process.on('SIGTERM') handler, call server.close() so the server stops accepting new connections while the existing requests complete, then close your database pools and other clients, and exit with code 0. You also add a timeout so one stuck request can't block shutdown forever, like if the drain hasn't finished in ten seconds or so, you just force-exit anyway. In Kubernetes this lines up with the pod lifecycle. The platform sends SIGTERM, waits out the termination grace period, then sends SIGKILL if the process is still alive. And I'd handle SIGINT the same way so local development stays consistent with production.

Basically you retry with exponential backoff and you cap the attempts. So wait one second, then two, then four, and give up after three to five tries or so. You add jitter, which is just a random component in the delay, so that a bunch of clients that failed at the same moment don't all come back at the same moment. And you only retry errors that are probably transient, like timeouts and 503s, and only on operations that are idempotent, where running them twice is harmless. For writes that aren't naturally idempotent there's the idempotency key thing, which lets the server deduplicate. Honestly libraries handle most of this for you, and a circuit breaker on top stops retrying entirely when the dependency looks properly down. The main things to avoid are retrying forever and hammering a service that's already struggling.

So a circuit breaker basically wraps your calls to a dependency and keeps track of failures. In the closed state, calls just pass through normally. When failures cross some threshold, the breaker opens, and after that calls fail immediately without even touching the dependency. That gives the struggling service room to recover, and your users don't sit through the full timeout wait. Then after a cooldown it goes half-open and lets one trial request through. If that succeeds the breaker closes, if it fails it opens again. You'd add one in front of any remote dependency that can fail or hang, so payment providers, third-party APIs, internal services, all of those qualify. Most teams just reach for a library like opossum rather than hand-rolling the state machine. And combined with retries and timeouts, it stops your service from repeatedly hammering something that's already down.

So streams report their failures through 'error' events, and the thing that trips people up is that .pipe() doesn't forward those errors. An error on one stream in the chain never reaches the others, so with a.pipe(b).pipe(c) I'd need an error listener on all three streams, which is easy to forget. Modern code uses stream.pipeline instead. It wires the stages together, forwards any error to a single callback, and cleans up every stream when something fails. There's also a promise-based version in stream/promises that works well with async/await. The rule I go by is pretty simple. .pipe() is fine for quick scripts, but production code should use pipeline, so a failure in any stage tears the whole chain down and hands me one error to handle.

The stack traces go missing because the callback runs later, on a completely different stack. By the time the async operation completes, the code that started it has already returned, so the trace only shows the completion machinery from the event loop. Async/await mostly fixes this, I believe V8 can stitch the awaited frames together, which is one more reason to prefer it over raw callbacks. Request context is about knowing which request produced an error five layers deep. The standard tool is AsyncLocalStorage. You run each request inside als.run(store, handler), and then anything transitively called can read the store, so your loggers pick up the request id on their own. Combine that with correlation ids passed between services and you get traceable errors without threading a context argument through every function signature.

So a health check is just an endpoint the platform polls to decide whether your instance is healthy, and the common setup splits it in two. Liveness answers, is the process alive. If it fails, the orchestrator restarts the pod. Readiness answers, can this instance serve traffic right now. If that fails, the instance drops out of the load balancer rotation but keeps running. The liveness one should be a cheap check that the process responds. Readiness can go further and verify that dependencies like the database or the cache are reachable, since serving without them would only produce errors anyway. You keep the endpoints fast, unauthenticated, and off to the side of normal routing. In Kubernetes these map to livenessProbe and readinessProbe, plus there's a startupProbe for apps that boot slowly.