Dead-Letter Queue
Fila de mensagens não processadas
Uma fila de mensagens não processadas mantém mensagens que uma fila de origem não conseguiu processar após suas tentativas permitidas. As pessoas podem inspecionar a falha antes de uma nova tentativa controlada.
source queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redriveemail_804✓fila principal continuaemail_803!endereço erradodead/email_803→inspecionar primeirosource queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redriveJOBOutro exemplo
A importação da linha `row-73` falha cinco vezes porque sua data está malformada. O Amazon SQS move a mensagem para uma DLQ. O alarme configurado da equipe então alerta um operador. Depois de corrigir o parser, o operador reenfileira um pequeno lote em uma taxa segura.
Partes principais
- 01Fila de origem
- 02Limite de tentativas
- 03motivo da falha
- 04Mensagem não processada
- 05Alerta e proprietário
- 06Inspecionar, corrigir e reenviar
Use-o quando
Use uma DLQ quando falhas repetidas devem parar de circular pela fila principal. Mantenha a razão, a origem, o número de tentativas, a idade da mensagem e um caminho seguro de redirecionamento.
Não o use quando
Não mova uma mensagem após a primeira falha curta, ignore uma DLQ crescente ou redirecione antes de corrigir a causa. Remover um item também pode quebrar um fluxo que exige ordem estrita.
Nome usado no código
source queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redrive Antes de lançar
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Complete the task with Fila de mensagens não processadas (Dead-Letter Queue). User context: A importação da linha `row-73` falha cinco vezes porque sua data está malformada. O Amazon SQS move a mensagem para uma DLQ. O alarme configurado da equipe então alerta um operador. Depois de corrigir o parser, o operador reenfileira um pequeno lote em uma taxa segura. Technical concept or control: Fila de mensagens não processadas (Dead-Letter Queue). Why it fits: Use uma DLQ quando falhas repetidas devem parar de circular pela fila principal. Mantenha a razão, a origem, o número de tentativas, a idade da mensagem e um caminho seguro de redirecionamento. Do not use it when: Não mova uma mensagem após a primeira falha curta, ignore uma DLQ crescente ou redirecione antes de corrigir a causa. Remover um item também pode quebrar um fluxo que exige ordem estrita. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): Nenhum padrão oficial único controla todo o termo. Seu significado pode mudar entre equipes, plataformas ou frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Conferir este pedido
Review how Fila de mensagens não processadas (Dead-Letter Queue) is used now. Definition: Uma fila de mensagens não processadas mantém mensagens que uma fila de origem não conseguiu processar após suas tentativas permitidas. As pessoas podem inspecionar a falha antes de uma nova tentativa controlada. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.