0Pricing
Serverless Backend with AWS Lambda & API Gateway · Lektion

Dead-Letter-Queues und Fehlerbehandlung

Nachrichten können bei der Verarbeitung fehlschlagen. Lernen Sie, wie Dead-Letter-Queues nicht verarbeitbare Nachrichten auffangen und wie Sie Retries und erneute Verarbeitung für robuste ereignisgesteuerte Systeme entwerfen.

Dead-Letter-Queues und Fehlerbehandlung ist eine kostenlose Serverless Backend with AWS Lambda & API Gateway-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Serverless Backend with AWS Lambda & API Gateway-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Serverless Backend with AWS Lambda & API Gateway-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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 All

Redriving 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

Häufig gestellte Fragen

Ist die Lektion „Dead-Letter-Queues und Fehlerbehandlung“ kostenlos?

Ja — der vollständige Text von „Dead-Letter-Queues und Fehlerbehandlung“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Serverless Backend with AWS Lambda & API Gateway-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Serverless Backend with AWS Lambda & API Gateway-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Dead-Letter-Queues und Fehlerbehandlung“?

Nachrichten können bei der Verarbeitung fehlschlagen. Lernen Sie, wie Dead-Letter-Queues nicht verarbeitbare Nachrichten auffangen und wie Sie Retries und erneute Verarbeitung für robuste ereignisges… Du übst Serverless Backend with AWS Lambda & API Gateway mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Serverless Backend with AWS Lambda & API Gateway zu starten?

Keine Vorkenntnisse erforderlich. Serverless Backend with AWS Lambda & API Gateway auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Dead-Letter-Queues und Fehlerbehandlung“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Serverless Backend with AWS Lambda & API Gateway-Lektion Code schreiben und ausführen?

Ja. Jede Serverless Backend with AWS Lambda & API Gateway-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. SQS zur Entkopplung von Services
  2. SNS für Pub/Sub-Messaging
  3. Lambda mit SQS/SNS-Triggern
  4. Dead-Letter-Queues und Fehlerbehandlung
← Zurück zu Serverless Backend with AWS Lambda & API Gateway