Health Endpoint Monitoring

Conceito

O serviço expõe um endpoint que informa seu estado, consumido por balanceador, orquestrador e monitoramento externo.

Os três probes

Confundir liveness com readiness é o erro mais caro do padrão: se o liveness verifica o banco e o banco fica lento, todas as instâncias reiniciam — transformando degradação em queda total.

Regra: liveness verifica só o processo; readiness verifica as dependências.

Resposta útil

{ "status": "degradado",
  "banco":  { "status": "ok",    "latencia_ms": 3 },
  "cache":  { "status": "falha", "erro": "timeout" } }

Estado ternário (ok / degradado / falha) é mais útil que binário: com o cache fora, o serviço está lento e funcional — e deve continuar recebendo tráfego.

Trade-offs

Check raso não detecta aplicação quebrada: um processo que responde 500 para tudo continua "vivo".

Check profundo propaga falha em cascata: se A verifica B, e B fica lento, A é retirado da rotação mesmo podendo atender as requisições que não dependem de B. A falha de B vira falha de A por decisão do monitoramento.

O equilíbrio é distinguir dependência crítica de opcional e reportar estado degradado em vez de binário.

Dois cuidados operacionais: o endpoint roda a cada poucos segundos por instância, então não deve ser custoso — três consultas pesadas multiplicadas por 50 instâncias viram carga significativa sobre o próprio banco monitorado. E não deve exigir autenticação, embora deva ser protegido de exposição pública, porque revela topologia interna.

Exemplo prático

GET /health/live   → 200 se o processo responde. Nada mais.
GET /health/ready  → 200 se banco OK e migrações aplicadas
                   → 503 se dependência crítica falhou

Durante um deploy, a instância nova responde live imediatamente, mas ready só depois que o pool de conexões aqueceu. O balanceador espera.

Isso elimina o sintoma clássico de deploy: as primeiras requisições da instância nova sofrendo timeout por terem chegado antes de ela estar realmente pronta.

Relacionado

• Deployment Stamps
• Geodes
• Throttling

---

Parte de Availability · roadmap.sh/system-design