SQS visibility timeouts, dead-letter queues and duplicates: what a managed queue does not do for you

A managed queue removes a real burden: nobody runs brokers, patches nodes or plans broker capacity. What it does not remove is the delivery semantics, and those are where most production surprises on SQS come from. Three behaviours are worth knowing exactly, all taken from AWS's own documentation.

Standard queues deliver at least once

Standard queues ensure at-least-once delivery, but because of their highly distributed architecture more than one copy of a message might be delivered, and messages may occasionally arrive out of order [1]. AWS's guidance is that standard queues suit applications that can handle messages arriving more than once or out of order [1].

In practice that makes consumer idempotency a design requirement, not a refinement. A consumer that charges a card, sends an email or increments a counter has to recognise a message it has already handled — typically by recording a message or business key and checking it before acting.

The visibility timeout is a lease, not a lock

When a consumer receives a message, the message stays in the queue but becomes invisible to other consumers for the visibility timeout — 30 seconds by default [2]. If the consumer does not delete it before the timeout expires, it becomes visible again and another consumer can receive it [2]. Even inside the timeout, AWS is explicit that the at-least-once model gives no absolute guarantee a message will not be delivered more than once [2].

• Too short, and work duplicates. A consumer still processing when the timeout expires will see the same message picked up by someone else.
• Too long, and failures wait. A consumer that crashes leaves its message invisible until the timeout runs out, which AWS notes can slow retries [2].
• Long jobs extend it. ChangeMessageVisibility extends the timeout while work continues, and AWS recommends a heartbeat that extends it periodically [2]. There is a hard ceiling: 12 hours from when the message was first received, which extending does not reset [2].

The dead-letter retention trap

A redrive policy's maxReceiveCount sets how many times a consumer can receive a message before it moves to the dead-letter queue [3]. Set it too low and a single transient failure dead-letters a healthy message; AWS's own example is a value of 1, where one failure is enough [3].

The subtler issue is retention. For standard queues, a message's expiry is based on its original enqueue time, and moving it to a dead-letter queue does not change that [3]. AWS's example: a message that spends one day in the source queue and moves to a dead-letter queue with four days' retention is deleted after three [3]. The recommendation is to always set the dead-letter queue's retention longer than the source queue's [3]. FIFO queues behave differently — there, the enqueue time resets on the move [3].

The wider point

A managed queue relocates operational burden rather than removing it: the broker becomes AWS's problem, and the delivery semantics stay yours. Engineers who have run SQS in production bring up idempotency keys, visibility heartbeats and dead-letter retention without being asked. Those three answers are a quick read on whether someone has operated it or only used it.