Cuando un servidor Node.js en producción se encuentra con un error asíncrono no capturado fuera de un bloque try/catch, el proceso entra en un estado inestable. Permitir que el servidor continúe operando en un estado corrupto es extremadamente peligroso, pero terminar el contenedor de inmediato interrumpe las transacciones HTTP activas de nuestros usuarios y deja conexiones huérfanas en el pool de la base de datos.
El Antipatrón Común: Reinicios Abruptos vs. Silencio de Errores
He observado que muchos desarrolladores cometen el error de simplemente ignorar los eventos globales de error o de invocar un process.exit(1) de forma inmediata. Esto provoca que las peticiones que estaban a mitad de camino se queden colgadas y que nuestra base de datos relacional sufra por bloqueos de tablas no liberados. La solución de nivel sénior requiere interceptar el fallo, rechazar nuevas peticiones, terminar el trabajo pendiente con un tiempo límite (timeout) y cerrar los sockets de forma limpia.
Implementación del Handler de Apagado Elegante (Graceful Shutdown)
Este snippet implementa lo que yo llamo un "búnker perimetral" de resiliencia. Escucha los eventos críticos del ciclo de vida del proceso de Node.js, interactúa con el servidor de Express y libera de forma atómica el pool de conexiones de la base de datos antes de devolver el código de salida correspondiente. Mi objetivo es asegurar que, incluso frente a un fallo crítico, nuestra aplicación se apague de la manera más controlada y menos disruptiva posible.