Express.js
Explica cómo diseñar endpoints de liveness y readiness que reflejen salud del proceso, disponibilidad de dependencias y capacidad real para recibir tráfico.
Liveness responde si el proceso debe reiniciarse. Readiness responde si debe recibir tráfico. Mezclarlas puede convertir una caída temporal de una dependencia en una tormenta de reinicios.
Las plataformas necesitan señales simples para decidir:
liveness
→ ¿el proceso sigue funcionando?
readiness
→ ¿puede atender requests correctamente ahora?
startup
→ ¿terminó una inicialización lenta?Debe ser barata y depender principalmente del proceso:
app.get('/health/live', (_request, response) => {
response.status(200).json({ status: 'alive' });
});No hagas una query a PostgreSQL en liveness. Si la DB cae, reiniciar todos los pods no la repara y puede empeorar la situación.
Evalúa dependencias necesarias para el contrato principal:
app.get('/health/ready', async (_request, response) => {
const databaseReady = await database.ping({ timeoutMs: 200 });
if (!databaseReady) {
response.status(503).json({ status: 'not_ready' });
return;
}
response.status(200).json({ status: 'ready' });
});Cuando falla, la plataforma retira la instancia del balanceo sin matarla inmediatamente.
Incluye una dependencia si el servicio no puede cumplir su función principal sin ella. No conviertas cualquier integración opcional en requisito de readiness.
Ejemplo:
Una probe frecuente puede convertirse en carga. Usa:
SELECT 1.No ejecutes migraciones, counts ni queries de negocio.
Una aplicación que carga modelos o ejecuta inicialización larga puede fallar liveness antes de estar lista. Una startup probe concede una ventana separada.
Idealmente las migraciones se ejecutan como proceso de deployment, no en cada instancia, para evitar carreras.
No expongas secretos, URLs internas, versiones detalladas, stack ni topología en endpoints públicos.
{ "status": "not_ready" }Los detalles viven en logs/métricas protegidas.
Puedes modelar readiness:
const readiness = {
acceptingTraffic: false,
database: false,
shuttingDown: false,
};Durante shutdown, marca not-ready antes de cerrar el servidor para permitir drenaje.
En Kubernetes:
Usa 200 para healthy/ready y 503 para not-ready. Añade Cache-Control: no-store para evitar respuestas cacheadas.
Mide cambios de readiness y duración. Una instancia oscilando entre estados puede indicar pool agotado, timeouts demasiado estrictos o dependencia inestable.
La probe no sustituye métricas de latencia, errores o saturación.
{healthy:false}.Graceful shutdown de un servidor Express coordina señales, tráfico, requests y dependencias.