Backfill Sem Derrubar Banco nem Fila

O problema

Toda mudança de schema, regra ou storage acaba encontrando esta frase:

“Depois a gente roda um backfill.”

Falado assim, parece detalhe.

Na prática, backfill pode:

• varrer tabela gigante
• encher fila
• saturar indice
• aumentar latência do sistema principal
• disparar side effect indevido

Ou seja, o “depois a gente roda” vira um incidente com nome mais educado.

Modelo mental

Pense assim:

backfill e uma carga operacional controlada para aproximar dado antigo do modelo novo

Não e só transformação.

E também controle de ritmo.

Você precisa pensar em:

• quanto processa por vez
• como mede impacto
• como pausa
• como retoma
• como evita duplicar trabalho ou side effect

Se esse desenho não existe, ainda não existe backfill seguro.

Quebrando o problema

Divida em lotes pequenos e observaveis

O pior backfill e o que tenta processar tudo de uma vez.

O caminho mais seguro costuma ter:

• chunk pequeno
• checkpoint
• progresso medivel
• pausa simples

Isso deixa a operação mais explicavel.

Também evita que você descubra tarde demais que o lote inteiro estava errado.

Controle ritmo como se fosse tráfego

Backfill concorre com produção pelos mesmos recursos.

Por isso vale perguntar:

• quantas linhas por segundo
• quantos jobs em paralelo
• qual horario reduz impacto
• quando desacelerar ou parar

Sem throttle, backfill não parece manutenção.

Parece ataque ao próprio banco.

Faca a operação ser retomavel

Backfill bom aceita interrupcao.

Se o processo cair no meio, você precisa saber:

• até onde foi
• o que ainda falta
• o que pode repetir sem dano

Isso puxa checkpoint, idempotencia e critério claro de progresso.

Separe preenchimento de side effect

Esse ponto evita desastre.

As vezes preencher dado novo e seguro.

Já republicar evento, reenviar email ou recalcular cobrança pode ser perigoso.

Backfill que dispara efeito colateral sem filtro costuma sair muito mais caro do que parecia.

Observe impacto enquanto roda, não só depois

Você precisa enxergar pelo menos:

• latência do banco
• fila acumulando
• erro do job
• throughput do processamento
• percentual concluido

Sem isso, o time só percebe problema quando o suporte ou o on-call já esta reclamando.

Exemplo simples

Imagine que a aplicação ganhou uma coluna normalized_email para busca mais eficiente.

Agora o time precisa preencher essa coluna para 80 milhoes de usuários antigos.

Plano ruim:

• script único
• UPDATE massivo
• roda e torce

Plano melhor:

1. processa usuários em lotes pequenos por faixa de id
2. grava checkpoint do ultimo lote concluido
3. limita concorrência
4. monitora impacto em CPU, lock e latência
5. pausa se o primary ou a fila comecarem a sofrer

Esse plano continua técnico, mas também continua operavel.

Erros comuns

• Tentar processar tudo em uma pancada só.
• Não separar backfill de tráfego principal.
• Ignorar idempotencia e checkpoint.
• Disparar side effect acidental durante a migração.
• Declarar backfill “simples” porque a regra de transformação parece curta.

Como um senior pensa

Quem tem mais experiência trata backfill como trabalho de produção com critério de operação.

A pergunta boa costuma ser:

“Se eu rodar isso hoje, qual recurso vai doer primeiro e como eu descubro antes de derrubar o resto?”

Essa pergunta melhora muito o plano.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você entende que preencher dado antigo também envolve capacidade, operação e risco real.

Você sobe de nivel quando:

• fala de chunking e throttle
• menciona checkpoint e retomada
• lembra de idempotencia
• considera impacto em banco, fila e side effect

Uma resposta forte costuma soar assim:

“Eu trataria o backfill como operação controlada: lotes pequenos, checkpoint, idempotencia, observabilidade e throttle. Só ampliaria o ritmo se o banco e os consumidores estivessem estaveis.”

Backfill seguro não e o mais rápido no papel. E o que termina sem incendiar o resto do sistema.

Quando o script parece fácil demais, normalmente a operação e que esta subestimada.