2 de Agosto de 2025
Reprocessamento seletivo por chave, janela ou tenant sem varrer o mundo inteiro
Quando algo quebra em produção, reprocessar tudo parece simples. Até virar custo enorme, duplicação acidental e nova indisponibilidade.
Andrews Ribeiro
Founder & Engineer
3 min Intermediario Sistemas
O problema
Quando um fluxo quebra, a reação mais tentadora é:
“roda tudo de novo”
Às vezes funciona.
Muitas vezes, cria outros problemas:
- custo alto
- fila congestionada
- duplicação de efeito colateral
- investigação mais difícil
Se só um subconjunto estava errado, varrer o mundo inteiro é um jeito caro de evitar pensamento mais preciso.
Modelo mental
Reprocessamento bom começa respondendo:
- qual recorte está afetado?
- como identifico esse recorte?
- o fluxo é idempotente o suficiente para repetir?
Três recortes aparecem muito:
- por chave
- por janela
- por tenant
Eles não resolvem tudo, mas já transformam recuperação em operação direcionada.
Exemplo simples
Imagine um bug em um job que calcula score de risco.
Você descobre que o problema afetou:
- pedidos entre 10h e 11h
- só do tenant
acme - e, dentro desse grupo, só os que tinham
payment_method = pix
Se a única ferramenta do sistema é “recalcular todos os pedidos dos últimos 30 dias”, você já perdeu bastante eficiência operacional.
Se o sistema aceita:
- reprocessar por janela
- limitar por tenant
- ou rodar só para chaves específicas
a correção fica muito mais controlada.
O erro comum
O erro comum é tratar replay total como estratégia padrão.
Isso costuma esconder falta de desenho em:
- filtro de escopo
- auditoria
- idempotência
- isolamento operacional
Outro erro comum é criar script one-off para cada incidente.
Funciona uma vez.
Mas não constrói capacidade operacional real.
O que normalmente ajuda
Reprocessamento seletivo melhor costuma pedir:
- identificador estável da unidade afetada
- marcação temporal confiável
- dimensão de segmentação como tenant, shard ou partição
- execução auditável com dry run, limite e visibilidade
Em muitos casos, vale oferecer mais de um modo:
- por lista de IDs
- por intervalo de tempo
- por tenant
Assim o time escolhe o menor raio de explosão possível.
Como um senior pensa
Quem já precisou corrigir produção sem derrubar o resto costuma perguntar:
- qual é o menor recorte que resolve o problema?
- consigo testar esse recorte antes de escalar?
- que efeito colateral pode duplicar?
- como observo progresso, falha e resultado do reprocessamento?
Essa é a diferença entre “temos um script” e “temos uma capacidade operacional”.
Ângulo de entrevista
Esse tema aparece em backend, filas, pipelines, dados derivados e incidentes.
O entrevistador quer ver se você entende:
- que replay total raramente é a melhor primeira opção
- que recorte operacional reduz risco e custo
- que reprocessamento seguro depende de idempotência, auditoria e controle de escopo
Resposta forte costuma soar assim:
“Eu evitaria reprocessar tudo por padrão. Preferiria capacidade seletiva por chave, janela ou tenant, com observação e limites. Isso reduz raio de explosão e torna a recuperação mais precisa.”
Takeaway direto
Reprocessamento saudável não é o que consegue repetir tudo.
É o que consegue repetir só o que precisa.
Resumo rápido
O que vale manter na cabeça
- Reprocessamento seguro normalmente precisa de recorte, não de replay total.
- Chave, janela e tenant são três formas úteis de reduzir escopo e risco operacional.
- Sem filtro de alvo e sem idempotência, reprocessar pode piorar o incidente.
- Operabilidade aqui significa conseguir corrigir só o pedaço quebrado com observação e controle.
Checklist de pratica
Use isto ao responder
- Consigo reprocessar só um conjunto pequeno afetado por bug ou atraso?
- Tenho como escolher por chave, intervalo de tempo ou tenant sem script artesanal novo?
- Se eu reexecutar esse fluxo, o sistema duplica efeito colateral?
- Consigo auditar o que foi reprocessado, por quê e com qual resultado?
Você concluiu este artigo
Compartilhar esta página
Copie o link manualmente no campo abaixo.