Dead Letter Queue

Was ist eine Dead Letter Queue?

Eine Dead Letter Queue (DLQ) ist der Ort, an dem Nachrichten landen, die die reguläre Verarbeitung aufgegeben hat. In asynchronen Systemen liest ein Consumer eine Nachricht, verarbeitet sie und bestätigt sie bei Erfolg. Schlägt die Verarbeitung fehl, wird die Nachricht wieder sichtbar und erneut versucht. Manche Nachrichten werden aber nie erfolgreich sein: fehlerhafte Payloads, Verweise auf gelöschte Datensätze oder ein Bug, den nur bestimmte Eingaben auslösen. Ohne DLQ wird eine solche Poison Message endlos wiederholt, verschwendet Kapazität und blockiert in geordneten Queues alles, was dahinter wartet.

Eine DLQ durchbricht diese Schleife. Nach einer festgelegten Zahl fehlgeschlagener Versuche, oder wenn eine Nachricht abgelehnt wird oder abläuft, verschiebt der Broker oder der Consumer sie zur Seite. Die Haupt-Queue läuft weiter, und die fehlgeschlagene Nachricht bleibt für Analyse und Replay erhalten.

So funktioniert eine Dead Letter Queue in gängigen Brokern

Amazon SQS

In SQS ist eine DLQ eine normale Queue, auf die die Redrive Policy der Quell-Queue verweist. Die Policy legt deadLetterTargetArn und maxReceiveCount fest: Wurde eine Nachricht so oft empfangen, ohne gelöscht zu werden, verschiebt SQS sie in die DLQ. Die DLQ muss denselben Typ haben wie die Quelle (Standard oder FIFO) und im selben Account und in derselben Region liegen. Eine Redrive Allow Policy an der DLQ steuert, welche Quell-Queues sie nutzen dürfen, und ein DLQ-Redrive verschiebt Nachrichten nach einem Fix zurück in die Quell-Queue. Bei Standard-Queues bleibt der ursprüngliche Enqueue-Zeitstempel erhalten. Die Aufbewahrungsdauer der DLQ sollte daher länger sein als die der Quell-Queue.

Apache Kafka

Kafka-Broker haben keine eingebaute DLQ. Ein Topic ist ein Log, und Consumer verwalten Offsets, statt einzelne Nachrichten zu bestätigen. Das Dead-Letter-Muster wird deshalb im Client oder Framework umgesetzt: Bei einem Fehler veröffentlicht der Consumer den Record, oft mit Fehlerdetails in Headern, in ein separates Topic wie orders.DLT, committet den Offset und macht weiter. Kafka Connect unterstützt das für Sink-Connectoren über errors.tolerance=all und errors.deadletterqueue.topic.name, Frameworks wie Spring for Apache Kafka bringen einen Dead Letter Publishing Recoverer mit. Viele Teams schalten zusätzlich Retry-Topics mit wachsender Verzögerung vor das finale Dead Letter Topic.

RabbitMQ

RabbitMQ arbeitet mit Dead Letter Exchanges (DLX), konfiguriert über das Queue-Argument x-dead-letter-exchange oder besser über eine Policy. Eine Nachricht wird „dead-lettered“, wenn ein Consumer sie mit requeue=false ablehnt oder per Nack zurückweist, wenn ihre TTL abläuft, wenn das Längenlimit der Queue überschritten wird oder wenn das Delivery Limit einer Quorum Queue erreicht ist. Seit RabbitMQ 4.0 gilt für Quorum Queues standardmäßig ein Delivery Limit von 20. Ohne Dead-Letter-Ziel werden Nachrichten darüber hinaus verworfen. Die Historie hält RabbitMQ im Header x-death fest.

Warum DLQs für die Zuverlässigkeit wichtig sind

• Isolation: Eine fehlerhafte Nachricht legt nicht eine ganze Partition oder Consumer Group lahm.
• Kein stiller Datenverlust: Gescheiterte Bestellungen, Zahlungen oder Events bleiben erhalten, statt verworfen zu werden.
• Bessere Fehlersuche: Die DLQ ist eine kuratierte Liste genau der Eingaben, die Ihr Code nicht verarbeiten kann.
• Kontrollierte Last: Zusammen mit Exponential Backoff zwischen den Versuchen begrenzt eine DLQ die Last, die fehlschlagende Nachrichten erzeugen.

Beispiel: eine SQS Redrive Policy

{
  "deadLetterTargetArn": "arn:aws:sqs:eu-central-1:123456789012:orders-dlq",
  "maxReceiveCount": "5"
}

In diesem illustrativen Setup erhält jede Bestellnachricht fünf Versuche. Bei einem Visibility Timeout von 60 Sekunden erreicht eine dauerhaft fehlschlagende Nachricht orders-dlq nach etwa fünf Minuten. Statt tagelanger Retries schlägt dann der Alarm auf der DLQ an.

Best Practices für das DLQ-Monitoring

• Alarmieren, sobald die DLQ nicht leer ist oder wächst. Eine gesunde DLQ ist meist leer, jede Queue Depth über null ist also ein Signal. Das Alter der ältesten Nachricht zeigt, wie lange ein Problem schon unbemerkt besteht.
• Kontext mitgeben. Speichern Sie Fehlermeldung, Verweis auf den Stacktrace, Anzahl der Versuche und Trace-ID mit der Nachricht, etwa in Headern oder Attributen.
• Transiente und dauerhafte Fehler trennen. Timeouts verdienen Retries, Validierungsfehler dürfen sofort in die DLQ.
• Einen Replay-Prozess definieren. Dokumentieren Sie, wie Nachrichten geprüft, korrigiert und zurückgespielt werden, und machen Sie Consumer idempotent, damit Replays sicher sind.
• Aufbewahrung bewusst wählen, damit Nachrichten nicht aus der DLQ verschwinden, bevor jemand sie angesehen hat.

Typische Fehler

• Eine DLQ anlegen, aber nie darauf alarmieren. So wird sie zum stillen Friedhof.
• Ein maxReceiveCount von 1, das Nachrichten schon beim ersten transienten Aussetzer in die DLQ schickt.
• Alles zurückspielen, ohne die Ursache zu beheben, sodass die Nachrichten sofort wieder zurückkommen.
• Die Verbindung zwischen einer Dead-Letter-Nachricht und dem Trace verlieren, der zeigt, warum sie gescheitert ist.

Wie Obseria hilft

Obseria überwacht Queue- und Topic-Metriken aus Brokern wie Amazon SQS und Kafka zusammen mit den Traces der Consumer. Eine wachsende DLQ lässt sich so mit dem Fehler und dem Deployment verknüpfen, die sie verursacht haben. Mehr dazu unter Queue Monitoring und Kafka Monitoring, wo Consumer Lag, Durchsatz und Dead Letter Topics in einer Ansicht zusammenlaufen.