Dead Letter Queue Retention
Each SQS queue can be configured with a redrive policy that specifies a dead letter queue that will receive messages that were not processed in a timely manner by the source queue. A common issue when setting up dead letter queues is that the messages may never actually reach the queue itself. This is caused when the retention of the dead letter queue is shorter than the retention of the source queue. When a message is sent to the dead letter queue, its original timestamp is used to determine how long it should be kept in the dead letter queue. If the retention of the dead letter queue is too small, then the message will get deleted when it arrives without ever becoming visible.
To solve this, ensure that the retention period of the dead letter queue is significantly longer than the longest retention period of any source queues.
Max Receives
When configuring the redrive policy on an SQS queue, you must set the number of maximum receives that a message may have before being automatically moved to the dead letter queue. Setting this value to "1" is not recommended, because there is a small chance that a failed ReceiveMessage call will cause the message to move straight to the dead letter queue without being processed.
Additionally, viewing messages in the SQS Console will count as a receive, and you may accidentally cause messages to enter the dead letter queue before your system could process them.
Make sure you allow multiple receives before sending messages to a dead letter queue.
Message Delay & Retention Period
Message delay is the amount of time it will take for a message to become visible for the first time when it is sent to a queue. Message retention is how long a message will remain in the queue before being automatically deleted. In SQS, it is possible to configure the delay time to be greater than the retention time, resulting in messages that are deleted before it is possible to consume them.
Ensure that your default queue delay is shorter than your retention and that you are not setting a delay higher than the retention in any "SendMessage" API calls.
Resources
