SQS delay queues vs visibility timeout: what's the difference?

Amazon SQS has three settings that make a message temporarily invisible: delay queues, message timers and the visibility timeout. They sound alike, and exam questions lean on that. The difference is simple once you ask one question: when does the message disappear, and why?

• A delay hides a message before anyone has received it. You’re saying “not yet”.
• The visibility timeout hides a message after a consumer has received it. You’re saying “someone’s working on this”.

The life of an SQS message

Picture one message going through a queue:

1. A producer sends the message.
2. Delay (optional): the message waits, invisible, for 0 to 15 minutes.
3. The message becomes available. A consumer calls ReceiveMessage and gets it.
4. Visibility timeout: the message is hidden from every other consumer while this one works on it. The default is 30 seconds; the maximum is 12 hours.
5. The consumer finishes and calls DeleteMessage. Done.
6. If the consumer doesn’t delete it in time (it crashed, or it was too slow), the message becomes visible again and another consumer can receive it.

SQS never deletes a message just because someone received it. Deleting is the consumer’s job, and the visibility timeout is the window it gets to do that.

Delay queues: hold every new message back

A delay queue is a normal queue with its DelaySeconds attribute set above zero. Every message sent to it stays invisible for that long before any consumer can receive it.

• Range: 0 seconds to 15 minutes (900 seconds). The default is 0, meaning no delay.
• It applies to every message sent to the queue.
• On a standard queue, changing the setting only affects messages sent afterwards. On a FIFO queue it also affects messages already waiting.

Use it when the rest of the system needs a head start: for example, an order event that shouldn’t be processed until a payment record has had time to land.

Message timers: hold back one message

A message timer is the same idea for a single message: set DelaySeconds on the SendMessage call instead of on the queue.

• Same range: 0 to 15 minutes.
• It overrides the queue’s delay for that one message.
• Standard queues only. FIFO queues don’t support per-message timers, only the queue-wide delay.

Use it when only some messages need to wait, such as a “retry in 5 minutes” message.

Visibility timeout: protect a message while it’s being worked on

The visibility timeout starts the moment a consumer receives a message. Until it runs out, no other consumer can receive that message, so two workers don’t process the same job at the same time.

• Default 30 seconds; range 0 seconds to 12 hours.
• Set it on the queue, or for one receive call.
• A consumer that needs longer can call ChangeMessageVisibility to extend it, up to the 12-hour maximum.

Getting it wrong shows up in two ways:

Set it a little longer than your normal processing time. Standard queues deliver at least once anyway, so make your consumers safe to run twice (idempotent) whatever you choose.

With AWS Lambda: six times the function timeout

When an SQS queue triggers a Lambda function, AWS recommends a queue visibility timeout of at least six times the function’s timeout. Lambda retries and batches messages, and a timeout that’s too short leads to the duplicate processing described above.

Dead-letter queues: where repeat failures go

Each time a message is received without being deleted, its receive count goes up. A dead-letter queue (DLQ) catches messages that keep failing: set a redrive policy with a maxReceiveCount, and after that many receives SQS moves the message to the DLQ instead of offering it again.

That keeps one broken message (a “poison pill”) from blocking or wasting your consumers, and gives you somewhere to inspect it. A FIFO queue’s DLQ must also be FIFO; a standard queue’s must be standard.

Side by side

There’s a third “wait” that’s easy to mix in: long polling. Setting WaitTimeSeconds (up to 20 seconds) makes a ReceiveMessage call wait for a message to arrive instead of returning empty straight away. It doesn’t hide anything; it just cuts down on empty responses and cost.

Exam traps

• “Messages are being processed more than once.” The visibility timeout is shorter than the processing time. Increase it, or have the consumer extend it. A delay queue won’t help.
• “Postpone every new message by a few minutes.” Delay queue.
• “Postpone only certain messages.” Message timer, which rules out a FIFO queue.
• “Postpone by more than 15 minutes.” That’s beyond SQS delays. Look for a scheduling service such as Amazon EventBridge Scheduler or a Step Functions wait state instead.
• “A few bad messages keep failing and retrying forever.” Dead-letter queue with a maxReceiveCount.
• “Lambda processes SQS messages twice.” Check that the visibility timeout is at least six times the function timeout.

For the full details, see the Amazon SQS Developer Guide on delay queues, message timers, visibility timeout and dead-letter queues.