System Design/01 - Fundamentos2 min
Fail-Over
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Failover é a transferência automática de operação de um componente que falhou para um componente reserva.
Modos
| Modo | Reserva está | RTO | Custo |
|---|---|---|---|
| Cold standby | Desligada | Horas | $ |
| Warm standby | Ligada, recebendo replicação, sem tráfego | Minutos | $$ |
| Hot standby / Active-Passive | Pronta para assumir imediatamente | Segundos | $$$ |
| Active-Active | Servindo tráfego o tempo todo | ~Zero | $$$$ |
Em active-passive, só o primário atende; o secundário monitora via heartbeat e assume quando o batimento cessa. Em active-active, ambos atendem e o balanceador simplesmente para de mandar tráfego para o que caiu — o failover é implícito.
As peças necessárias
- Detecção — health check, heartbeat, timeout
- Decisão — quem declara o primário morto (e evita declarar em falso)
- Promoção — o secundário vira primário
- Redirecionamento — DNS, IP virtual, service discovery, balanceador
Trade-offs
O problema difícil não é a mecânica do failover — é decidir que houve falha.
Split-brain é o modo de falha característico: a rede se parte, o secundário conclui que o primário morreu e se promove, e passa a existir dois primários aceitando escritas. Quando a rede volta, há dois históricos divergentes e nenhuma forma automática segura de uni-los.
As defesas usuais:
| Defesa | Como funciona |
|---|---|
| Quórum | Só se promove quem tem a maioria dos votos |
| Fencing / STONITH | Desliga fisicamente o nó antigo antes de promover |
| Lease | O primário renova um contrato com prazo; sem renovação, expira |
| Testemunha | Um terceiro nó desempata |
O outro trade-off é a sensibilidade da detecção: timeout curto causa failover desnecessário (que é, ele mesmo, uma indisponibilidade); timeout longo aumenta o RTO real.
Exemplo prático
Um banco relacional em active-passive com replicação assíncrona. O primário morre com 3 segundos de transações ainda não replicadas.
O failover funciona — o secundário assume em 30 segundos. E aquelas transações estão perdidas: o RPO não é zero, é ~3 segundos. Se eram pagamentos confirmados ao cliente, o sistema confirmou algo que não existe mais.
A escolha entre replicação síncrona (RPO zero, latência maior em toda escrita) e assíncrona (latência baixa, RPO > 0) é feita antes do incidente. Failover não conserta a decisão de replicação.
Relacionado
Parte de Availability Patterns · roadmap.sh/system-design