DAllgemein

Dead Letter Queue (DLQ)

Ablage für fehlgeschlagene Nachrichten/Jobs zur späteren Analyse.

Eine Dead Letter Queue (DLQ) ist eine separate Warteschlange (Ablage), in der fehlgeschlagene Nachrichten oder Jobs landen, wenn sie in einem automatisierten Prozess nicht erfolgreich verarbeitet werden können. Statt den gesamten Workflow zu blockieren oder Nachrichten still zu verlieren, werden diese „Problemfälle“ isoliert gespeichert, damit Teams sie später analysieren, korrigieren und – wenn sinnvoll – erneut verarbeiten können.

Was bedeutet Dead Letter Queue (DLQ)?

„Dead Letter“ kommt aus der Messaging-Welt und meint Nachrichten, die ihr Ziel nicht erreichen: z. B. weil Daten ungültig sind, ein Zielsystem nicht erreichbar ist oder ein Verarbeitungsschritt wiederholt fehlschlägt. Eine DLQ ist damit eine Art Quarantänebereich für Ausnahmen in Integrationen, Event-Processing und Prozessautomatisierung.

Wie funktioniert eine Dead Letter Queue (DLQ)?

  • Normaler Ablauf: Eine Nachricht (z. B. „Rechnung erstellen“) wird aus einer Queue gelesen und verarbeitet.
  • Fehler tritt auf: Der Worker/Workflow kann nicht erfolgreich abschließen (z. B. Validierungsfehler, Timeout, API-Fehler).
  • Retries & Backoff: Oft wird zunächst automatisch erneut versucht (mit Wartezeit). Nach X Fehlversuchen gilt die Nachricht als „nicht verarbeitbar“.
  • Verschieben in die DLQ: Die Nachricht wird inklusive Metadaten (Fehlergrund, Timestamp, Attempt-Count, Payload) in die DLQ abgelegt.
  • Analyse & Reprocessing: Menschen oder ein separater Prozess prüfen die DLQ, beheben Ursachen (z. B. Mapping, Stammdaten, Berechtigungen) und stoßen eine erneute Verarbeitung an.

Warum ist eine DLQ wichtig – gerade für wachsende KMU?

Wenn manuelle Prozesse durch Automatisierung (Automation) ersetzt werden, steigen Volumen und Komplexität: mehr Systeme, mehr Schnittstellen, mehr Sonderfälle. Ohne DLQ führen einzelne „kaputte“ Nachrichten schnell zu Rückstaus, wiederholten Fehlversuchen, unklaren Datenständen oder stillen Datenverlusten. Eine DLQ schafft hier Stabilität: Der Hauptprozess läuft weiter, und Fehler werden strukturiert auffindbar.

Typische Vorteile:

  • Fehlertransparenz: Statt „irgendwas ist schiefgelaufen“ sehen Teams konkrete Payload + Fehlermeldung.
  • Skalierbarkeit: Ausnahmen werden entkoppelt, der Standardfluss bleibt performant.
  • Bessere Qualität: Wiederkehrende Fehler lassen sich erkennen (z. B. falsche Felder aus einem Formular) und systematisch abstellen.
  • Compliance & Nachvollziehbarkeit: Problemfälle sind dokumentiert und können auditiert werden (wichtig bei Buchhaltung, Bestellungen, Support-Tickets).

Beispiele aus der Praxis

  • CRM → ERP: Ein Auftrag wird übertragen, aber die Kundennummer fehlt. Der Auftrag landet in der DLQ, damit er nach Stammdaten-Korrektur erneut gesendet werden kann.
  • E-Mail-/Ticket-Automation: Ein Workflow erstellt ein Ticket, aber die Helpdesk-API liefert 429 (Rate Limit). Nach mehreren Retries geht der Job in die DLQ zur späteren Wiederholung.
  • Dokumentenverarbeitung: Ein OCR/IDP-Schritt liefert ein unerwartetes Format. Die Nachricht wird in der DLQ gespeichert, um das Parsing zu verbessern und den Fall erneut zu verarbeiten.

Was kostet eine Dead Letter Queue (DLQ)?

Eine DLQ ist meist kein eigenes „Produkt“, sondern eine Funktion von Messaging- oder Workflow-Systemen. Kosten entstehen typischerweise durch Speicher, Nachrichtenvolumen und Monitoring/Operations. In der Praxis ist eine DLQ oft „günstig“ im Vergleich zu den Kosten von Datenverlust, manueller Fehlersuche und Prozessstillständen.

Best Practices (kurz)

  • Klare Kriterien: Wann wird in die DLQ verschoben (z. B. nach 5 Retries)?
  • Gute Metadaten: Fehlercode, Stacktrace/Reason, Correlation-ID, Zeitpunkt, Version des Workflows.
  • Alerting: Benachrichtigung bei DLQ-Anstieg (z. B. Slack/E-Mail), damit Fehler nicht „liegen bleiben“.
  • Reprocessing-Plan: UI/Runbook, wie Nachrichten geprüft und sicher erneut gestartet werden.