System Design/01 - Fundamentos2 min
Availability in Numbers
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Disponibilidade se expressa em "noves" — a fração do tempo em que o sistema responde corretamente.
| Noves | Disponibilidade | Downtime/ano | Downtime/mês | Downtime/semana |
|---|---|---|---|---|
| Dois | 99% | 3,65 dias | 7,2 h | 1,68 h |
| Três | 99,9% | 8,77 h | 43,8 min | 10,1 min |
| Quatro | 99,99% | 52,6 min | 4,38 min | 1,01 min |
| Cinco | 99,999% | 5,26 min | 26 s | 6 s |
| Seis | 99,9999% | 31,5 s | 2,6 s | 0,6 s |
Como a disponibilidade se compõe
Em série (a requisição depende de todos): as disponibilidades se multiplicam — o resultado é sempre pior que o pior componente.
99,9% × 99,9% × 99,9% = 99,7% (3 serviços em série)
Dez serviços a 99,9% em série entregam 99,0% — de 8,8 h para 87 h de downtime por ano.
Em paralelo (redundância, basta um funcionar): as indisponibilidades se multiplicam.
1 - (0,1% × 0,1%) = 99,9999% (2 réplicas a 99,9%)
É essa assimetria que justifica redundância: dois componentes medíocres em paralelo batem um componente excelente.
Trade-offs
Cada nove adicional custa aproximadamente uma ordem de grandeza a mais — em infraestrutura, em processo e em disciplina operacional. Passar de 99,9% para 99,99% raramente é problema de tecnologia; é problema de deploy, observabilidade e tempo de resposta humano.
O número também precisa de contexto: 99,9% medido como? Média mensal esconde uma queda de 40 minutos. E disponibilidade do componente não é disponibilidade do usuário — um sistema "no ar" respondendo erro 500 conta como disponível em muitas medições ingênuas.
Por fim, o SLA prometido deve ser menor que a disponibilidade real observada: a folga é o que evita pagar multa por variação normal.
Exemplo prático
Uma arquitetura com CDN (99,99%) → load balancer (99,99%) → app (99,95%) → banco (99,95%), tudo em série:
0,9999 × 0,9999 × 0,9995 × 0,9995 ≈ 99,88% → ~10,5 h de downtime/ano
Prometer 99,95% nesse desenho é prometer o que a arquitetura não entrega. Para chegar lá, o caminho é redundância no elo mais fraco — banco em réplica com failover — não otimizar o que já está em 99,99%.
Relacionado
Parte de Availability Patterns · roadmap.sh/system-design