Um sistema de pedidos orientado a eventos usa uma fila SQS standard do Amazon. Durante os testes, o processamento parou porque uma única mensagem de pedido causou um erro de backend e bloqueou as mensagens subsequentes. O tempo limite de visibilidade da fila é de 30 segundos, enquanto o tempo limite de processamento do backend é de 10 segundos. Um arquiteto de soluções deve permitir a investigação de mensagens com falha e garantir que as mensagens subsequentes continuem sendo processadas. O que o arquiteto de soluções deve fazer?

A opção correta é criar uma fila SQS standard e configurá-la como uma dead-letter queue (DLQ). Isso permite que mensagens que falham repetidamente no processamento, como a mensagem de pedido com erro, sejam automaticamente movidas para a DLQ após um número configurável de tentativas (redrive policy). Isso isola a mensagem problemática, permitindo que as mensagens subsequentes na fila principal continuem sendo processadas, e a DLQ pode ser inspecionada para depuração. Aumentar o tempo limite de processamento do backend não resolve o problema da mensagem com erro, apenas atrasa a reprocessamento. Reduzir o tempo limite de visibilidade do SQS faria com que a mensagem com erro voltasse à fila mais rapidamente, exacerbando o problema de bloqueio. Usar uma fila SQS FIFO como DLQ não é necessário, pois a ordem não é crítica para mensagens com falha e as filas FIFO têm menor throughput e maior custo.