O sistema envia uma operação, a conexão cai e a resposta não chega. O trabalho falhou ou foi concluído antes da interrupção? Essa dúvida aparece em integrações e explica por que tentar novamente exige mais cuidado do que repetir uma chamada.
Entenda o que cada confirmação garante
Uma fila pode confirmar que recebeu uma mensagem, enquanto o consumidor ainda não executou a tarefa. Depois, o consumidor confirma seu processamento. A documentação do RabbitMQ diferencia confirmações de publicação e de consumo; elas acompanham partes distintas do percurso.
A garantia final depende também de como a mensagem é persistida, de quando a confirmação acontece e do comportamento da operação de negócio. A presença de uma fila, por si só, não resolve todas essas decisões.
Dê uma identidade estável à operação
Uma chave de idempotência permite reconhecer novas tentativas do mesmo trabalho. Ela precisa representar a operação pretendida, e não ser recriada a cada envio. Guarde o resultado aceito de forma que uma repetição não produza um segundo efeito.
Se a operação altera o banco, o registro da chave e a mudança de negócio precisam ser coordenados. Caso contrário, uma falha entre essas etapas ainda pode deixar espaço para duplicação. Quando o efeito acontece em um serviço externo, verifique quais proteções esse serviço oferece.
Diferencie falhas temporárias de dados inválidos
Uma dependência indisponível pode voltar. Um campo obrigatório ausente não será corrigido apenas esperando. Classifique as falhas para decidir o que merece nova tentativa e o que precisa de intervenção.
- Use intervalos entre tentativas, em vez de repetir sem pausa.
- Defina limite de tentativas ou de tempo para o trabalho.
- Encaminhe falhas persistentes para uma área de análise.
- Preserve a identidade da operação em um reprocessamento manual.
Observe idade e acúmulo da fila
Uma fila com poucas mensagens muito antigas pode indicar trabalho parado. Acompanhe quantidade pendente, idade do item mais antigo e falhas de processamento. Relacione cada mensagem ao fluxo de negócio para que alguém consiga decidir o que fazer.
Inclua alertas com responsáveis e uma ação definida. Um painel sem acompanhamento não impede que uma integração acumule tarefas por dias.
Teste a falha entre o efeito e a resposta
Simule uma queda depois de realizar a operação, mas antes da confirmação. Repita a mensagem e confira se o resultado permanece correto. Esse cenário mostra se o sistema está preparado para a incerteza que mais frequentemente leva a efeitos duplicados.
Leitura complementar: confirmações de publicação e consumo na documentação do RabbitMQ.
