Dead-Letter Queue
A dead-letter queue keeps messages that a source queue could not process after its allowed attempts. People can inspect the failure before a controlled retry.
source queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redriveemail_804✓main queue continuesemail_803!bad addressdead/email_803→inspect firstsource queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redriveJOBAnother example
Import row `row-73` fails five times because its date is malformed. Amazon SQS moves the message to a DLQ. The team's configured alarm then alerts an operator. After fixing the parser, the operator redrives a small batch at a safe rate.
Main parts
- 01Source queue
- 02Attempt limit
- 03Failure reason
- 04Dead-letter message
- 05Alert and owner
- 06Inspect, fix, and redrive
Use it when
Use a DLQ when repeated failures should stop cycling through the main queue. Keep the reason, source, attempt count, message age, and a safe redrive path.
Do not use it when
Do not move a message after the first short failure, ignore a growing DLQ, or redrive before fixing the cause. Removing one item can also break a flow that requires strict order.
Name used in code
source queue + receive count > limit -> DLQ + configured monitor -> alert -> inspect/fix -> controlled redrive Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Dead-Letter Queue for this system while keeping data correct, secure, and easy to operate. User context: Import row `row-73` fails five times because its date is malformed. Amazon SQS moves the message to a DLQ. The team's configured alarm then alerts an operator. After fixing the parser, the operator redrives a small batch at a safe rate. Technical concept or control: Dead-Letter Queue. Why it fits: Use a DLQ when repeated failures should stop cycling through the main queue. Keep the reason, source, attempt count, message age, and a safe redrive path. Do not use it when: Do not move a message after the first short failure, ignore a growing DLQ, or redrive before fixing the cause. Removing one item can also break a flow that requires strict order. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Dead-Letter Queue. Definition: A dead-letter queue keeps messages that a source queue could not process after its allowed attempts. People can inspect the failure before a controlled retry. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.