SQS Dead-Letter Queues (DLQs)

Ref: https://learn.cantrill.io/courses/1820301/lectures/42318772

SQS Dead-Letter Queue (DLQ)

🔧 Queue where problematic messages are brought to for special processing
- Helps handle reoccurring failures of message/event processing
- 💡 Without DLQ, messages can be reprocessed frequently without ever leaving the queue
  - Reprocessing would not be forever, since e.g. SQS has a time limit of 14 days in a queue, but it still could be reprocessed maaany times, which you don't normally want
Redrive policy: defines what to do with problematic messages → Configuration:
- SRC queue to monitor
- DLQ queue to which problematic messages are sent (”redriven”)
- Conditions that, if met, will move messages from SRC to DLQ → must define a maxReceiveCount!
A single DLQ can be used for multiple SRC queues
Every time a message is processed in SRC queue, its ReceiveCount is incremented by 1
- If a message's ReceiveCount reaches maxReceiveCount, that message is sent to DLQ
Actions that can be taken in a DLQ:
- Alarm can be configured to e.g. notify of a message entering DLQ
- Perform separate, isolated diagnostics (separate environment from SRC queue)
  - e.g. examine logs or contents of message
- Special, separate processing for problematic messages can be tested or applied

🔧 All SQS messages have retention periods, i.e. how long they can stay in SQS
- If retention period expires, message is dropped
- When message is added to a queue, it gets an enqueue timestamp
  - Timestamp determines when message was added, allows comparing to retention period to see if message should be dropped
‼️ Enqueue timestamp is NOT adjusted when moving a message to a DLQ!!!
- 💡 If DLQ has retention period of 2 days, and a message that existed in SRC queue for 1 day enters the DLQ, it will ONLY stay in the DLQ for 2-1=1 day!!
- ❗ Generally, retention period in DLQs should be longer than SRC queues!
  - To avoid messages from disappearing immediately after entering DLQ