Reprocessamento Seguro Sem Duplicar Efeito Colateral

O problema

Sistema real falha.

Mensagem fica na fila.

Job cai no meio.

Integração externa volta depois.

Mais cedo ou mais tarde, alguém precisa reprocessar.

E e exatamente aqui que muita aplicação descobre que sabia “rodar uma vez”, mas não sabia “rodar de novo com segurança”.

Os estragos classicos sao conhecidos:

• cobrança dupla
• email duplicado
• estoque baixado outra vez
• evento republicado sem controle

Ou seja, reprocessamento vira multiplicador de dano.

Modelo mental

Pense assim:

reprocessar e repetir a mesma intenção, não inventar uma nova

Essa frase muda tudo.

Se a intenção e a mesma, o sistema precisa reconhecer:

• o que já foi feito
• o que faltou fazer
• o que pode ser repetido sem dano
• o que precisa ser protegido contra duplicação

Sem essa separação, todo reprocessamento fica perigoso por definição.

Quebrando o problema

Diferencie computação de efeito colateral

Nem tudo que acontece no fluxo tem o mesmo peso.

Recalcular um valor em memória pode ser inocente.

Já repetir:

• cobrança
• envio de email
• baixa de estoque
• publicação de evento externo

Pode ser gravissimo.

O primeiro passo e identificar onde o dano duplo realmente acontece.

Descubra a unidade da intenção

Reprocessamento seguro costuma depender de uma chave clara:

• payment_id
• order_id
• job_id
• event_id

Sem isso, o sistema não sabe se esta vendo a mesma operação de novo ou uma operação nova parecida.

Quando a unidade da intenção fica nebulosa, a proteção também fica.

Guarde evidencias do que já foi aplicado

Você precisa de algum mecanismo para responder:

isso já foi processado?

Esse mecanismo pode estar em:

• tabela de processamento
• idempotency key
• estado do job
• event log
• marca de checkpoint

O formato varia.

A necessidade não.

Reprocesse por etapas quando o fluxo e grande

Fluxo longo costuma falhar no meio.

Entao o sistema precisa saber:

• se repete tudo
• se retoma de um ponto
• se compensa o que já foi aplicado

Responder isso cedo evita muito improviso depois.

Não trate “retry”, “reprocessar” e “reconciliar” como a mesma coisa

Retry automático costuma ser rápido e local.

Reprocessamento pode ser tardio e manual.

Reconciliação compara estados e corrige divergencia.

Misturar tudo sob o mesmo nome deixa a operação confusa e a proteção incompleta.

Exemplo simples

Imagine um fluxo de pedido pago:

1. salva pagamento confirmado
2. baixa estoque
3. envia email
4. publica evento para ERP

O worker cai depois do passo 2.

Se alguém simplesmente reexecutar tudo, pode:

• baixar estoque de novo
• mandar email duplicado

Plano melhor:

• reconhecer o payment_id como a mesma intenção
• verificar quais passos já foram aplicados
• repetir só o que ainda falta ou garantir idempotencia em cada side effect

Isso da mais trabalho.

Também impede que “resolver falha” crie uma falha nova.

Erros comuns

• Reenfileirar sem saber o que já aconteceu.
• Confiar que efeito colateral externo vai tolerar duplicação.
• Não ter chave clara para identificar a mesma intenção.
• Reprocessar tudo por padrão quando o fluxo falha no meio.
• Chamar de retry algo que na prática e reconciliação manual.

Como um senior pensa

Quem tem mais experiência não pergunta só:

“Como eu rodo de novo?”

Pergunta mais isto:

“Qual parte eu posso repetir sem dano e qual parte precisa de prova de que ainda não aconteceu?”

Essa pergunta costuma separar sistema robusto de sistema fragil.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você entende que falha repetida e comportamento normal do ambiente, não acidente raro.

Você sobe de nivel quando:

• fala de intenção e não só de execução
• separa computação de side effect
• menciona idempotencia, deduplicação ou checkpoint
• reconhece diferença entre retry, reprocessamento e reconciliação

Uma resposta forte costuma soar assim:

“Eu trataria reprocessamento como repetição da mesma intenção. Para isso, preciso de identificador claro, registro do que já foi aplicado e proteção nos side effects para não cobrar, enviar ou publicar duas vezes.”

Reprocessar bem não e apertar o mesmo botao de novo. E saber exatamente o que esse botao já fez antes.

Quando reprocessamento cria dano novo, o sistema ainda não aprendeu a falhar com maturidade.