Walk me through deploying a new version of a Node service without dropping a single request.
A good answer ties each deploy-window error signature to its specific race and owns the app's side of the contract a rolling restart depends on.
You run multiple instances and replace them one at a time. Bring up a new instance, wait for its health check to pass, shift traffic over to it, then send SIGTERM to an old one, and that kicks off graceful shutdown, so it stops accepting new connections, finishes the in-flight requests, and exits before the platform's grace period runs out. Kubernetes rolling updates, blue-green, canary, they're all basically the same swap with a different order and blast radius. The app really has two jobs in all of this. Handle SIGTERM properly, and report readiness accurately so the balancer only routes to instances that can actually serve. If you do it right, capacity stays above demand the whole time and clients never notice anything. The usual failures are instances getting killed mid-request, or traffic getting sent to instances that aren't ready yet.