قوائم الانتظار للحروف الميتة ومعالجة حالات الفشل

In an event-driven system a message may fail repeatedly — bad data, a downstream outage, or a bug. Without a safety net, it can block the queue or be lost forever.

A dead-letter queue (DLQ) is a separate queue that captures messages that could not be processed after a set number of attempts. This isolates poison messages without losing them.

An SQS queue routes to a DLQ via a redrive policy that names the DLQ and a maxReceiveCount. After that many failed receives, the message moves to the DLQ.

Async Lambda invocations (S3, SNS) can send failures to a DLQ or to an on-failure destination via the event invoke config.

Too low and transient blips dead-letter good messages; too high and a poison message wastes many retries. A value of 3 to 5 is a common starting point.

Messages in the DLQ keep the original body plus attributes showing why they failed. Read them to diagnose the root cause before reprocessing.

Once the bug is fixed, SQS can redrive messages from the DLQ back to the source queue for reprocessing — no manual copying needed.

Because retries and redrives can deliver the same message more than once, your handler must be idempotent: processing the same message twice should not double-charge or duplicate records.

A growing DLQ is a signal something is broken. Set a CloudWatch alarm on the DLQ ApproximateNumberOfMessagesVisible metric to get notified.

When Lambda reads a batch from SQS, reporting batchItemFailures lets only the failed messages return to the queue, instead of reprocessing the whole batch.

A resilient pipeline combines:

• Retries for transient errors
• A DLQ for poison messages
• Idempotent handlers
• Alarms and a redrive plan

You learned to handle failing messages:

• A DLQ isolates poison messages after maxReceiveCount
• Configure redrive policies and Lambda on-failure destinations
• Inspect, fix, then redrive messages back
• Make handlers idempotent and alarm on DLQ depth
• Use batchItemFailures for partial batch retries