Dead-letter queue e gestione dei fallimenti
I messaggi possono non essere elaborati. Scopra come le dead-letter queue raccolgono i messaggi nocivi e come progettare retry e rielaborazione per sistemi resilienti basati sugli eventi.
Dead-letter queue e gestione dei fallimenti è una lezione Serverless Backend with AWS Lambda & API Gateway gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Serverless Backend with AWS Lambda & API Gateway, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Serverless Backend with AWS Lambda & API Gateway include 4 lezioni in totale.
Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.
The Problem of Failing Messages
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.
What is a Dead-Letter Queue?
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.
Redrive Policy
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.
{
"deadLetterTargetArn": "arn:aws:sqs:us-east-1:123:orders-dlq",
"maxReceiveCount": 5
}Configuring a DLQ for Lambda
Async Lambda invocations (S3, SNS) can send failures to a DLQ or to an on-failure destination via the event invoke config.
aws lambda put-function-event-invoke-config \
--function-name processOrder \
--destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:orders-dlq"}}'Setting maxReceiveCount Wisely
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.
Inspecting Dead-Lettered Messages
Messages in the DLQ keep the original body plus attributes showing why they failed. Read them to diagnose the root cause before reprocessing.
aws sqs receive-message \
--queue-url https://sqs.../orders-dlq \
--attribute-names AllRedriving Messages Back
Once the bug is fixed, SQS can redrive messages from the DLQ back to the source queue for reprocessing — no manual copying needed.
Idempotency Matters
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.
Alerting on the DLQ
A growing DLQ is a signal something is broken. Set a CloudWatch alarm on the DLQ ApproximateNumberOfMessagesVisible metric to get notified.
Partial Batch Failures
When Lambda reads a batch from SQS, reporting batchItemFailures lets only the failed messages return to the queue, instead of reprocessing the whole batch.
{
"batchItemFailures": [
{ "itemIdentifier": "msg-id-3" }
]
}Designing for Resilience
A resilient pipeline combines:
- Retries for transient errors
- A DLQ for poison messages
- Idempotent handlers
- Alarms and a redrive plan
Quick Check
Test your failure-handling knowledge.
Recap
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
Domande Frequenti
La lezione «Dead-letter queue e gestione dei fallimenti» è gratuita?
Sì — il testo completo di «Dead-letter queue e gestione dei fallimenti» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Serverless Backend with AWS Lambda & API Gateway, passa a CoddyKit PRO. Il corso Serverless Backend with AWS Lambda & API Gateway include 4 lezioni in totale.
Cosa imparerò in «Dead-letter queue e gestione dei fallimenti»?
I messaggi possono non essere elaborati. Scopra come le dead-letter queue raccolgono i messaggi nocivi e come progettare retry e rielaborazione per sistemi resilienti basati sugli eventi. Eserciti Serverless Backend with AWS Lambda & API Gateway con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Serverless Backend with AWS Lambda & API Gateway?
Non è richiesta alcuna esperienza precedente. Serverless Backend with AWS Lambda & API Gateway su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «Dead-letter queue e gestione dei fallimenti»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Serverless Backend with AWS Lambda & API Gateway?
Sì. Ogni lezione Serverless Backend with AWS Lambda & API Gateway include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- SQS per disaccoppiare i servizi
- SNS per la messaggistica Pub/Sub
- Trigger Lambda con SQS/SNS
- Dead-letter queue e gestione dei fallimenti