Custom consumers receive from an SQS Standard queue and normally take 90 seconds to process a message. VisibilityTimeout is 30 seconds, and DeleteMessage is called after success.
Logs confirm another consumer receives the same message after the 30-second visibility expiry. Reduce this redelivery while retaining retries for processing failures.
Which mitigation is most appropriate?
Cover normal work with VisibilityTimeout and extend before expiry to reduce expiry-related redelivery; retain successful deletion and idempotency.
Detailed explanation
Retention controls how long the queue stores a message; it does not extend invisibility after receipt.
Retention controls how long the queue stores a message; it does not extend invisibility after receipt.
Delivery delay affects newly sent messages' initial visibility, not the processing window of a received message.
Delivery delay affects newly sent messages' initial visibility, not the processing window of a received message.
Deleting first prevents a queue retry after a processing failure, contrary to the requirement.
Deleting first prevents a queue retry after a processing failure, contrary to the requirement.
Align the invisibility window with processing and delete after success. Idempotency is still required for possible Standard-queue duplicates.
Align the invisibility window with processing and delete after success. Idempotency is still required for possible Standard-queue duplicates.
Check official documentation
Compare the following points with the official documentation.
Review visibility expiry, ChangeMessageVisibility, deletion after success, and Standard at-least-once delivery.
Official references
What to confirm
Explain why 120 seconds covers the observed expiry and why duplicate-safe processing remains necessary.
Key points
- VisibilityTimeout
- Duplicate delivery
- SQS consumer
Notes
- Environment: AWS SOA-C03 exam guide and the linked AWS documentation
- Reviewed against the linked AWS documentation on 2026-10-04.
Foundation review
Balance processing time and retry delay
For normal 90-second work, a 120-second visibility window provides headroom. Extend longer work with ChangeMessageVisibility before the current deadline and delete after success using the receipt handle. Excessively long visibility delays failure retries. Extensions do not reset the maximum 12 hours from receipt.
Invisibility does not guarantee zero duplicates
Standard queues provide at-least-once delivery and can deliver duplicates even during the visibility interval. Tuning addresses the observed expiry, not an absolute duplicate guarantee. Track processed work using an order ID or another suitable key so receiving a message again does not repeat its side effects.