System Design/01 - Fundamentos1 minindice
Availability Patterns
Padrões
Medindo
Perguntas-guia
- Como esses tópicos se encaixam entre si?
- Qual escolher em qual cenário?
Visão geral
Disponibilidade se conquista com redundância — e redundância exige decidir o que o reserva faz enquanto não é necessário.
| Padrão | Reserva | RTO | Custo |
|---|---|---|---|
| Fail-Over active-passive | Espera, replicando | Segundos a minutos | $$$ |
| Fail-Over active-active | Serve tráfego | ~Zero | $$$$ |
| Replication | Cópias do dado | Depende da promoção | $$ |
Availability in Numbers fornece a aritmética que orienta a decisão:
- Componentes em série multiplicam disponibilidades → o total é sempre pior que o pior elo
- Componentes em paralelo multiplicam indisponibilidades → dois componentes medíocres batem um excelente
É essa assimetria que justifica redundância em vez de perseguir um componente perfeito.
Dois pontos que a prática ensina e a teoria esconde:
- O problema difícil não é o failover, é a detecção. Declarar falha cedo demais causa failover desnecessário (que é, ele mesmo, indisponibilidade); tarde demais aumenta o RTO. E declarar em falso dos dois lados produz split-brain.
- Replicação assíncrona implica RPO maior que zero. O failover pode funcionar perfeitamente e ainda assim perder as últimas transações.
Parte de 01 - MOC Fundamentos · roadmap.sh/system-design