Health check endpoint
Una URL especial (a menudo /healthz o /readyz) que un servicio expone únicamente para informar sobre su propia salud. Balanceadores de carga, sondas de Kubernetes y sistemas de monitorización la consultan para decidir si el servicio debe recibir tráfico.
Patrón: el servicio responde 200 OK si está sano, o un código de error si no. Hay dos profundidades: una comprobación superficial (liveness) —¿el proceso responde siquiera?— y una profunda (readiness) —¿puede realmente hacer su trabajo, llega a la base de datos, ha llenado su caché? La convención /healthz viene de Google/Kubernetes (la z para evitar chocar con páginas reales). Caso de uso: las sondas liveness/readiness de Kubernetes la consultan, los balanceadores de carga dejan de enviar tráfico a una instancia cuyo health check falla, y el service discovery filtra las instancias no sanas. Trampa: un health check demasiado profundo (que prueba todas las dependencias) puede provocar fallos en cascada — si una base de datos compartida se vuelve lenta, TODOS los servicios se reportan como no sanos y se retiran del tráfico a la vez → hay que diseñarlos con cuidado. Una pieza clave de los sistemas autorreparables y observables. Relacionado con la readiness probe y el service discovery.