An event-driven ordering system uses an Amazon SQS standard queue. During testing, processing stopped because a single order message caused a backend error and blocked subsequent messages. The queue visibility timeout is 30 seconds, while backend processing times out after 10 seconds. A solutions architect must allow investigation of faulty messages and ensure subsequent messages continue to be processed. What should the solutions architect do?

The correct solution is to create a new SQS standard queue and configure it as a dead-letter queue (DLQ). A DLQ isolates messages that cannot be successfully processed, preventing them from blocking the main queue. When a message fails processing multiple times (as determined by a maxReceiveCount policy), SQS automatically moves it to the DLQ. This allows subsequent messages in the main queue to be processed without interruption, while the faulty message can be investigated separately in the DLQ. Increasing the backend processing timeout to 30 seconds might delay the error detection but won't resolve the fundamental issue of a faulty message blocking the queue if the error persists. Reducing the SQS visibility timeout would cause the faulty message to be re-delivered more quickly, potentially exacerbating the problem by increasing the load on the backend with repeated failures. Using an SQS FIFO queue as a DLQ is unnecessary because the primary goal is to isolate faulty messages, not to maintain strict ordering for them. A standard queue is sufficient and more cost-effective for a DLQ.