Poison message, DLQ e quarentena

O problema

Fila saudável aceita erro eventual.

Mas existe um tipo de mensagem que entra no modo:

• falha
• retry
• falha de novo
• retry de novo

E não melhora.

Essa mensagem começa a ocupar tempo, throughput e paciência do sistema inteiro.

Se ela continua voltando para a fila principal sem critério, o dano cresce:

• consumidor perde tempo em looping
• mensagens boas esperam atrás
• o time para de confiar no fluxo

É aí que nasce a poison message.

Modelo mental

Pense assim:

poison message é a mensagem que já mostrou que retry cego não está resolvendo

O importante aqui não é o nome.

É a mudança de estratégia.

Enquanto a falha parece transitória, retry faz sentido.

Quando fica claro que a mensagem está quebrada, fora de contrato ou presa em erro sem saída, insistir é só espalhar estrago.

Quebrando o problema

Nem toda falha repetida é poison message

Se a falha vem de:

• timeout temporário
• dependência instável
• pico curto

retry ainda pode ser a resposta certa.

Poison message aparece mais quando o problema é:

• payload inválido
• formato inesperado
• dado impossível de processar
• bug determinístico do consumidor

Ou seja, a chance de sucesso não está subindo com a repetição.

DLQ existe para proteger o fluxo principal

Dead letter queue tem um papel simples:

• tirar a mensagem problemática do caminho das mensagens saudáveis

Isso evita que a fila principal vire refém de um caso ruim.

Mas DLQ não é resolução.

É isolamento.

Quarentena e triagem importam mais do que a fila em si

Depois que a mensagem sai da fila principal, o time ainda precisa saber:

• por que ela foi para lá
• quantas foram
• qual impacto representam
• o que fazer com elas

Sem triagem, a DLQ vira cemitério:

• muita coisa enterrada
• pouca investigação
• nenhum aprendizado

Reprocessar mensagem ruim sem entender causa raiz só muda a fila do problema

Tem time que drena DLQ e reenfileira tudo de uma vez.

Se a causa continua viva, o sistema ganha:

• outro looping
• mais ruído
• menos confiança

Reprocessamento bom pede classificação:

• erro já corrigido
• dado ainda inválido
• caso que precisa intervenção manual

Quarentena pode ser mais útil que falha definitiva em alguns fluxos

Em fluxo sensível, faz sentido segurar a mensagem em área separada com:

• contexto
• motivo da falha
• metadado para análise

Isso ajuda a decidir:

• corrigir e reenviar
• descartar
• compensar manualmente

Exemplo simples

Imagine um consumidor de order_paid.

Uma mensagem chega com campo obrigatório ausente por causa de bug antigo no produtor.

O consumidor tenta processar:

• falha na validação
• retry acontece
• falha igual

Depois de algumas tentativas, insistir não ajuda mais.

Plano melhor:

1. mandar a mensagem para DLQ
2. registrar motivo da falha
3. alertar o time
4. corrigir produtor ou consumidor
5. reenfileirar só o subconjunto que agora tem chance real de passar

Assim, a fila principal continua viva e o erro fica visível em vez de escondido no looping.

Erros comuns

• Tratar qualquer erro como retry infinito.
• Mandar mensagem para DLQ sem metadado útil.
• Não monitorar volume e causa das mensagens em quarentena.
• Reenfileirar tudo sem corrigir a origem.
• Deixar DLQ existir como depósito sem dono nem processo.

Como um senior pensa

Quem tem mais experiência pergunta:

“Essa mensagem ainda tem chance real de sucesso, ou eu só estou gastando processamento para provar o mesmo erro mais uma vez?”

Essa pergunta evita muito ritual de retry.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você sabe proteger o fluxo principal sem esconder a falha debaixo do tapete.

Você sobe de nível quando:

• diferencia falha transitória de poison message
• explica o papel de DLQ e quarentena
• lembra que alguém precisa olhar e agir sobre a fila de falha
• conecta reprocessamento à causa raiz, não a reflexo operacional

Uma resposta forte costuma soar assim:

“Eu usaria retry para falha transitória, mas quando a mensagem mostra erro repetido sem perspectiva de melhora, ela sai da fila principal para DLQ ou quarentena. A partir dali, eu preciso de triagem, causa raiz e critério de reprocessamento para não transformar a fila de falha em cemitério.”

DLQ boa não é a que recebe muita mensagem. É a que ajuda o time a recuperar sinal sem perder o fluxo saudável.

Quando retry vira ritual, poison message vira problema do sistema inteiro.