SAA-C03 Practice Question 5: SQS Visibility Timeout Duplicates

The default visibility timeout on an SQS queue is 30 seconds, and the clock starts the moment the message is delivered. If the consumer has not deleted the message by the time the timeout expires, SQS makes it visible again and any consumer may receive it. With processing now averaging 45 seconds, most messages become visible again before the payment call finishes and the DeleteMessage lands; a second worker picks the same message up and charges the customer again. The correlation with the release that pushed processing past 30 seconds is the giveaway.

The fixes follow directly: raise the queue's visibility timeout above the worst-case processing time, and for jobs of variable duration have the worker extend it with ChangeMessageVisibility as a heartbeat (up to the 12-hour ceiling measured from first receipt). Because SQS standard queues are at-least-once, the payment call should also be made idempotent.

Option A misstates the delivery model. Standard queues are *at-least-once*, meaning a message may occasionally be delivered more than once; they do not systematically deliver everything twice, and that would not explain why the problem started with a specific release.

Option C describes the wrong knob. Long polling (WaitTimeSeconds) controls how long ReceiveMessage waits for messages to arrive before returning, which reduces empty responses and request cost. It has no bearing on whether a message already in flight is handed to a second consumer.

Option D has the causality backwards. A dead-letter queue caps redelivery once maxReceiveCount is exceeded; it is a containment mechanism for messages that repeatedly fail. Here the messages are not failing at all; they are succeeding at the payment API and simply being reprocessed. A DLQ would not prevent the second charge.

Reference: Amazon SQS visibility timeout