Dead-Letter Queue (DLQ)

No modelo mais comum, o broker conta quantas vezes uma mensagem foi recebida ou devolvida sem conclusão. Quando o contador ultrapassa o limiar, a mensagem sai do fluxo principal e entra na DLQ. Amazon SQS configura isso em uma redrive policy com `deadLetterTargetArn` e `maxReceiveCount`. Um valor de 5, por exemplo, significa que o consumidor terá várias oportunidades antes da quarentena. O número não deve ser escolhido por hábito. Se a dependência costuma recuperar em 10 min e as retentativas ocorrem em segundos, cinco tentativas podem ser insuficientes. Se o erro é permanente, cem tentativas apenas aumentam custo e atraso. A política deve trabalhar com backoff, visibility timeout e classificação de falhas. A mensagem também precisa manter ID, timestamp, origem e motivo para que o diagnóstico não dependa apenas do payload.

RabbitMQ utiliza dead-letter exchanges. Uma mensagem pode ser republicada para a exchange configurada quando é rejeitada com `requeue=false`, expira por TTL, ultrapassa limite de comprimento ou excede limite de entregas em estruturas compatíveis. A exchange aplica routing key e envia a uma ou mais filas de quarentena. Esse desenho permite separar erros de validação, indisponibilidade externa e expiração. A configuração pode ser feita por policy, preferível a argumentos rígidos quando a operação precisa mudar sem redeclarar filas. O cabeçalho de morte registra histórico conforme o broker. O consumidor da DLQ não deve simplesmente devolver tudo à origem. Primeiro classifica, corrige causa e decide redrive. Uma rota equivocada pode criar ciclo entre fila principal e DLQ. Métricas precisam distinguir novas mortes de reprocessamentos.

Serviços como Azure Service Bus, Google Pub/Sub e plataformas serverless oferecem dead-letter subqueue ou tópico de falhas. Mensagens podem ir para esse destino por contagem de entregas, expiração, filtro inválido, tamanho, sessão ou falha da função, conforme o produto. O consumidor precisa conhecer a semântica específica. Em Azure Service Bus, a dead-letter subqueue permanece vinculada à fila ou assinatura e não é limpa automaticamente apenas por existir. Em Google Pub/Sub, a política de dead lettering encaminha após tentativas aproximadas e exige permissões adequadas para o service agent. O nome DLQ não garante a mesma ordem, retenção ou contagem entre produtos. A integração deve registrar o motivo original e as propriedades do serviço antes de normalizar para um painel comum.

Em Apache Kafka e arquiteturas de streaming, a DLQ costuma ser implementada como tópico separado, como `telemetry.invalid.v1` ou `commands.dlq`. O consumidor captura exceção, produz um envelope com tópico de origem, partição, offset, chave, schema, erro e stack resumida, e então avança o offset original conforme a política. Esse avanço evita travar a partição, mas transfere a responsabilidade ao fluxo de quarentena. Se a ordem é crítica, retirar uma mensagem pode permitir que eventos posteriores sejam processados antes da correção. Em dados de sensor isso pode ser aceitável; em comandos sequenciais, talvez não. Retry topics temporizados podem preceder a DLQ. O envelope não deve incluir segredos ou dados pessoais desnecessários. O reprocessador precisa restaurar a chave e preservar idempotência.