Migrar um banco de dados de 10TB com zero downtime: qual é o plano?

Question

IT Interview Practice · Accepted Answer

**Faça dual-write no antigo e no novo, faça backfill do histórico em background, use CDC para alcançar o tail, verifique com shadow reads, depois vire as leituras atomicamente — com um caminho de rollback em cada passo.** Você nunca derruba o app; roda ambos os bancos em paralelo até que o novo seja comprovadamente idêntico, então faz o cutover.

## Arquitetura

```text
        ┌── write ──▶ OLD DB (source of truth) ──CDC (Debezium)──┐
 App ───┤                                                        ▼
        └── write ──▶ NEW DB ◀──── backfill job (historical rows)
                        │
   shadow reads (compare OLD vs NEW) ─▶ diff metrics ─▶ atomic cutover ─▶ NEW is truth
                                                          (flip flag; rollback = flip back)
```

## Como funciona

1. **Dual-write.** O app escreve toda mudança tanto no OLD quanto no NEW. Novas linhas ficam em sincronia a partir de agora; só o histórico está faltando.
2. **Backfill.** Um job em background copia linhas históricas em lotes (throttled para proteger a prod). Use `INSERT ... ON CONFLICT DO NOTHING` para que seja idempotente e seguro para re-rodar.
3. **Catch-up de CDC.** O dual-write pode perder linhas escritas durante a ativação. O **Debezium** fazendo streaming do WAL/binlog do OLD DB faz replay de toda mudança, fechando a lacuna que o backfill não consegue.
4. **Shadow reads.** Leia do NEW em paralelo com o OLD, **compare os resultados** e emita uma métrica de diff. Zero diffs ao longo do tempo = NEW é confiável.
5. **Cutover.** Vire uma feature flag para que as leituras (depois as escritas) vão para o NEW. É uma mudança de config, não um deploy — instantânea, e **reversível virando de volta**.

## Perspectiva de entrevista

O entrevistador quer **como você garante nenhuma perda de dados e nenhum downtime**, e se você tem um **rollback**. Boas respostas mencionam dual-write; respostas excelentes adicionam **CDC para pegar a janela de race**, **shadow reads para verificar antes de confiar** e um **flip de flag atômico e reversível**. A armadilha clássica é "backfill e depois switch" sem verificação — você descobre a incompatibilidade depois que os usuários a atingem, sem volta.

## Trade-offs e falhas

- **Consistência do dual-write.** Se a escrita no NEW falha mas o OLD tem sucesso, eles divergem. Torne o OLD autoritativo e deixe o CDC reparar o NEW, em vez de falhar a requisição do usuário.
- **Custo e complexidade.** Rodar dois bancos + CDC + backfill é caro e operacionalmente pesado — justificado apenas para stores grandes e críticos.
- **Mudanças de schema** durante a migração multiplicam o risco; congele o schema até o cutover.
- **Carga do backfill.** Um backfill sem throttle pode saturar o I/O da prod e causar uma indisponibilidade — o oposto do objetivo; faça em lotes e com rate-limit.
- **Janela de rollback.** Mantenha o dual-write (agora NEW→OLD) por dias após o cutover para poder virar de volta se um bug latente surgir. Só então desative o OLD.
- **Quando não usar:** um DB pequeno com uma janela de manutenção não precisa disso — um `pg_dump`/restore de 30 minutos é mais simples e seguro que um pipeline CDC.

Arquitetura

Como funciona

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas