一個事件驅動的訂購系統使用 Amazon SQS standard queue。在測試期間，處理停止了，因為單一訂單訊息導致後端錯誤並阻塞了後續訊息。佇列可見性逾時為 30 秒，而後端處理在 10 秒後逾時。解決方案架構師必須允許調查錯誤訊息並確保後續訊息繼續被處理。解決方案架構師應該怎麼做？

正確答案是建立一個新的 SQS standard queue，並將其配置為 dead-letter queue (DLQ) 以隔離錯誤訊息。當訊息處理失敗時，DLQ 會接收這些訊息，使其不會阻塞主佇列，並允許後續訊息繼續處理。這也提供了調查錯誤訊息的機會。 將後端處理逾時增加到 30 秒只是延遲了問題，並不能解決根本的錯誤訊息。減少 SQS visibility timeout 會導致錯誤訊息更快地重新回到主佇列，可能導致無限循環的處理失敗，而不是解決問題。建立 SQS FIFO queue 作為 DLQ 是不必要的，因為主佇列是 standard queue，且 FIFO 佇列有更高的成本和更嚴格的限制，對於隔離錯誤訊息來說並非最佳選擇。