Purpose and setup of a Dead-Letter Queue

WHAT THIS TESTS This verifies you can design reliable message processing that neither loses data nor lets a single bad message stall a queue, a core event-driven concern.

A GOOD ANSWER COVERS A Dead-Letter Queue is a secondary queue that receives messages the primary consumer repeatedly fails to process. Its purpose is to isolate poison messages, a malformed payload or one that triggers a bug, so they stop being redelivered endlessly, stop blocking healthy messages, and are preserved for inspection instead of dropped. For a serverless consumer reading from a queue, you configure a redrive policy on the source queue specifying the DLQ and a maxReceiveCount. Each failed processing attempt makes the message visible again after the visibility timeout; once it has been received maxReceiveCount times without a successful delete, the queue moves it to the DLQ. You then alarm on DLQ depth, examine the failures, fix the bug or the data, and redrive the messages back to the source queue for reprocessing.

COMMON WRONG ANSWERS Treating the DLQ as a place to ignore errors rather than investigate them. Forgetting to alarm on it, so failures pile up unseen. Setting no max receive count, causing infinite retries that waste resources. Confusing a DLQ with a delay queue or a retry queue. Assuming the function code, rather than the queue redrive policy, routes messages to the DLQ in the queue-polling model.

LIKELY FOLLOW-UPS How does visibility timeout interact with retries? What is redrive and how do you trigger it? How do you prevent the DLQ itself overflowing? When would you add exponential backoff before the DLQ?

ONE CONCRETE EXAMPLE An order-processing function fails on a malformed message. With maxReceiveCount of five, after five failed receives the message lands in orders-dlq. A CloudWatch alarm fires on depth above zero; an engineer inspects the payload, fixes the parser, and redrives the queued messages, so nothing is lost and the main queue keeps flowing for valid orders.