Como você projeta um DB multi-region para HA e DR?

Question

IT Interview Practice · Accepted Answer

Replique o banco de dados entre regiões e escolha sua topologia pela necessidade: **active-passive** (um writer, um warm standby que assume no failover) para simplicidade e consistência forte, ou **active-active** (múltiplos writers) para baixa latência de escrita ao custo de resolução de conflitos — depois escolha **replicação sync vs async** para trocar durabilidade por latência, e defina metas explícitas de **RPO/RTO** que dirigem o failover.

```text
        ┌──────────── Region A (primary) ────────────┐
writes ─▶ app ─▶ DB primary ──┐
                              │ replication
        ┌─────────────────────┼── async (RPO>0) ─────┐
        │                     └── sync (RPO=0, slow)  │
        ▼                                             ▼
   Region B standby                            (failover promotes standby)
        │
   health check ──▶ on primary loss: promote + repoint DNS/traffic
```

## Active-passive vs active-active

**Active-passive** tem um primário lidando com escritas e standbys que só leem; na falha você **promove** um standby. É simples e evita conflitos de escrita, mas a capacidade passiva fica ociosa e o failover tem uma lacuna. **Active-active** deixa toda região aceitar escritas para latência local e sem promoção de failover — mas duas regiões podem editar a mesma linha concorrentemente, então você *deve* resolver conflitos (last-write-wins, CRDTs ou merge no nível da aplicação). A maioria dos times começa active-passive; active-active é para latência de escrita global que você genuinamente não consegue atingir de outra forma.

## Replicação sync vs async

Este é o trade-off central de durabilidade/latência. **Síncrona:** o primário espera a réplica remota confirmar antes de comitar — **RPO = 0** (sem perda de dados no failover) mas toda escrita paga a latência de ida e volta cross-region (~dezenas de ms), e se a réplica estiver inalcançável, as escritas travam. **Assíncrona:** o primário comita localmente e envia as mudanças depois — escritas rápidas, mas uma perda de região pode perder os últimos segundos (**RPO > 0**). Sync cross-region é frequentemente lento demais, então muitos rodam async e aceitam um RPO pequeno.

## Failover, RPO e RTO

- **RPO (Recovery Point Objective):** quanto de dados você pode perder — definido por sync vs async.
- **RTO (Recovery Time Objective):** quanto tempo até você estar de volta — definido por quão rápido você detecta a falha e promove.
- Failover = detectar (health checks) → promover standby → redirecionar tráfego (DNS/global LB). Automatize, mas proteja contra **split-brain** (ambas as regiões pensam que são primárias) com um quorum/fencing token.

## Perspectiva de entrevista

A sondagem: você entende que HA/DR é um **trade-off entre consistência, latência e perda de dados** — não "só adicionar uma réplica". Bom: active-passive com um standby. Excelente: você declara RPO/RTO, as implicações de sync-vs-async e o risco de split-brain. Armadilha: afirmar que async dá zero perda de dados, ou assumir que o failover é instantâneo e sem perdas.

## Trade-offs e modos de falha

- **Split-brain:** uma partição de rede promove dois primários → dados divergentes. Use quorum, fencing ou uma região testemunha.
- **Failback é difícil:** depois que o primário antigo volta, reconciliar escritas divergentes é manual e propenso a erros.
- **Custo:** multi-region verdadeiro aproximadamente dobra a infra e adiciona contas de banda de egress cross-region.
- **Failover não testado falha:** DR que nunca foi ensaiado não funcionará na indisponibilidade real — faça game-days.

Active-passive vs active-active

Replicação sync vs async

Failover, RPO e RTO

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas