Antrean Dead-Letter dan Penanganan Kegagalan
Pesan dapat gagal diproses. Pelajari cara antrean dead-letter menampung pesan beracun, serta cara merancang percobaan ulang dan pemrosesan ulang untuk sistem berbasis peristiwa yang tangguh.
Antrean Dead-Letter dan Penanganan Kegagalan adalah pelajaran Serverless Backend with AWS Lambda & API Gateway gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Serverless Backend with AWS Lambda & API Gateway, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Serverless Backend with AWS Lambda & API Gateway mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
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
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Antrean Dead-Letter dan Penanganan Kegagalan” gratis?
Ya — teks lengkap “Antrean Dead-Letter dan Penanganan Kegagalan” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Serverless Backend with AWS Lambda & API Gateway, upgrade ke CoddyKit PRO. Kursus Serverless Backend with AWS Lambda & API Gateway mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Antrean Dead-Letter dan Penanganan Kegagalan”?
Pesan dapat gagal diproses. Pelajari cara antrean dead-letter menampung pesan beracun, serta cara merancang percobaan ulang dan pemrosesan ulang untuk sistem berbasis peristiwa yang tangguh. Kamu berlatih Serverless Backend with AWS Lambda & API Gateway dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai Serverless Backend with AWS Lambda & API Gateway?
Tidak diperlukan pengalaman sebelumnya. Serverless Backend with AWS Lambda & API Gateway di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Antrean Dead-Letter dan Penanganan Kegagalan” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran Serverless Backend with AWS Lambda & API Gateway ini?
Ya. Setiap pelajaran Serverless Backend with AWS Lambda & API Gateway menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- SQS untuk Memisahkan Layanan
- SNS untuk Pesan Pub/Sub
- Lambda dengan Pemicu SQS/SNS
- Antrean Dead-Letter dan Penanganan Kegagalan