Dead Letter Queue
Ablage für nicht verarbeitbare Nachrichten
Die Idee und ihr Nutzen
Ein Maklerportal schickt Schadenmeldungen an eine Versicherung, und eine davon enthält kein Schadendatum. Der Meldedienst der Versicherung, der aus jeder Meldung einen Schaden anlegt, lehnt diese Meldung deshalb ab. Die Meldungen warten in der Hauptwarteschlange, einem Zwischenspeicher, der sie dem Meldedienst eine nach der anderen zustellt. Die Hauptwarteschlange stellt eine abgelehnte Meldung nach einer Pause erneut zu, weil manche Fehler nur vorübergehend sind; nach drei Versuchen ist ein solcher Fehler meist behoben. Am fehlenden Schadendatum ändert eine erneute Zustellung aber nichts. Nach dem dritten gescheiterten Versuch verschiebt die Hauptwarteschlange die Meldung in eine gesonderte Ablage. Das Betriebsteam der Versicherung klärt das fehlende Datum und stellt die Meldung danach erneut in die Hauptwarteschlange ein. So geht keine Meldung unbemerkt verloren, und keine hält die anderen auf. Die gesonderte Ablage heißt Dead Letter Queue, auf Deutsch etwa Ablage für unzustellbare Briefe.
Wie funktioniert es?
Um 10 Uhr spielt ein Versicherungsmakler eine neue Version seines Maklerportals ein. Durch einen Programmierfehler in der neuen Version fehlt in manchen Schadenmeldungen das Schadendatum. Das Maklerportal legt diese Meldungen wie alle anderen in die Hauptwarteschlange, und die Hauptwarteschlange stellt sie dem Meldedienst zu. Der Meldedienst lehnt jede Meldung ohne Schadendatum mit dem Grund „Schadendatum fehlt“ ab, weil ohne dieses Pflichtfeld kein Schaden angelegt werden darf. Die Hauptwarteschlange stellt eine abgelehnte Meldung nach einer Pause erneut zu. Nach dem dritten abgelehnten Versuch verschiebt die Hauptwarteschlange die Meldung mit Fehlergrund und Zahl der Versuche in die Dead Letter Queue. Alle anderen Meldungen verarbeitet der Meldedienst wie gewohnt. Die „Überwachung“ ist ein Programm, das die Meldungen in der Dead Letter Queue zählt und dem Betriebsteam einmal pro Stunde meldet, wenn welche hinzugekommen sind. So bekommt das Betriebsteam bei einer Häufung wie dieser eine einzige Nachricht statt Dutzender. Um 11 Uhr meldet die „Überwachung“ dem Betriebsteam, dass seit 10 Uhr 37 Meldungen aussortiert wurden, alle vom Maklerportal und alle mit dem Fehlergrund „Schadendatum fehlt“. Das Betriebsteam informiert den Makler und trägt kein Datum selbst ein. Der Makler behebt seinen Programmierfehler und liefert für die 37 Meldungen die tatsächlichen Schadendaten nach. Danach ergänzt das Betriebsteam die gelieferten Daten in den aussortierten Meldungen und stellt die Meldungen wieder in die Hauptwarteschlange ein. Der Meldedienst verarbeitet die 37 Meldungen nun ohne Fehler.
Das Maklerportal schickt seine Meldungen nicht direkt an den Meldedienst, sondern an eine Nachrichtenplattform. Das ist ein Programm, das Nachrichten in Warteschlangen wie der Hauptwarteschlange zwischenspeichert und an ihre Empfänger zustellt, hier an den Meldedienst. Über die Hauptwarteschlange kommen laufend Schadenmeldungen vieler Kunden beim Meldedienst an. Die Dead Letter Queue ist eine zweite Warteschlange auf derselben Nachrichtenplattform. Hat der Meldedienst eine Meldung verarbeitet, bestätigt er das der Hauptwarteschlange, und die Hauptwarteschlange löscht die Meldung. Scheitert die Verarbeitung, bleibt die Meldung für den nächsten Versuch in der Hauptwarteschlange. Manche Meldungen scheitern nur an einem vorübergehenden Fehler, zum Beispiel weil ein Vertragssystem kurz nicht erreichbar ist. Andere Meldungen scheitern bei jedem Versuch, weil der Fehler in der Meldung selbst liegt: Ein Pflichtfeld fehlt, die Meldung ist nur halb übertragen und lässt sich nicht lesen, oder die Vertragsnummer gibt es nicht.
Zu jeder aussortierten Meldung sollten Fehlergrund, Zahl der Versuche und Zeitpunkt festgehalten werden. Welche dieser Angaben die Nachrichtenplattform selbst mitschreibt, hängt vom Produkt und seiner Einstellung ab; den Rest muss der Meldedienst ergänzen. Ein Mensch oder ein Prüfprogramm ist dafür zuständig, jede aussortierte Meldung zu klären und sie danach erneut in die Hauptwarteschlange einzustellen oder mit einer dokumentierten Begründung zu verwerfen. Bei den Meldungen des Maklerportals ist das Betriebsteam zuständig.
Das fehlende Schadendatum hätte der Meldedienst schon beim ersten Versuch als dauerhaften Fehler erkennen können. Weil er die Meldung nur ablehnt und die Hauptwarteschlange den Fehlergrund nicht auswertet, wurde jede dieser Meldungen trotzdem dreimal zugestellt. Ein Fehler kann in der Meldung selbst liegen, etwa ein fehlendes Pflichtfeld oder eine nur halb übertragene Meldung. Erkennt der Meldedienst einen solchen Fehler, sollte er die Meldung sofort selbst in die Dead Letter Queue verschieben. So entfallen die zwei weiteren Zustellungen, die am Fehler nichts ändern. Wiederholungen helfen nur bei vorübergehenden Fehlern.
Dead Letter Queue: fehlerhafte Maklermeldungen aussortieren
Wann ist es sinnvoll und wann nicht?
Eine Dead Letter Queue lohnt sich
- Nachrichten kommen über eine Warteschlange an, und manche davon können fehlerhaft sein. Das trifft nahezu immer zu. Ohne Dead Letter Queue wird eine fehlerhafte Meldung immer wieder zugestellt und scheitert immer wieder. Je nach Einstellung der Hauptwarteschlange hält die fehlerhafte Meldung dabei alle Meldungen auf, die nach ihr eingegangen sind.
- Keine Nachricht darf stillschweigend verloren gehen. Hinter jeder Schadenmeldung steht ein Kunde, der auf eine Antwort wartet. Würde eine fehlerhafte Meldung einfach gelöscht, ginge die Schadenmeldung eines Kunden verloren, und niemand würde es merken.
- Die Nachrichten kommen von fremden Systemen wie dem Maklerportal. Das Maklerportal gehört dem Makler, nicht der Versicherung. Die Versicherung kann weder den Code des Maklerportals noch den Zeitpunkt seiner Updates beeinflussen und Fehler wie das fehlende Schadendatum deshalb nicht verhindern. Ohne Dead Letter Queue scheitern die fehlerhaften Meldungen des Maklerportals immer wieder, und die Versicherung bemerkt sie womöglich erst, wenn Kunden nachfragen. Mit Dead Letter Queue liegen die Meldungen gesammelt bereit, bis der Makler die fehlenden Daten nachliefert.
- Das Betriebsteam soll erkennen, woher gehäufte Fehler kommen. Ohne Dead Letter Queue stehen die 37 Ablehnungen verstreut zwischen Tausenden anderer Einträge im Protokoll des Meldedienstes. Fehlergrund und Herkunft zeigen dem Betriebsteam um 11 Uhr, dass alle 37 aussortierten Meldungen vom selben Maklerportal stammen.
- Die Nachrichtenplattform kann das Verschieben übernehmen. Dann braucht der Meldedienst keine selbst programmierte Ablage für gescheiterte Meldungen.
Eine Dead Letter Queue ist nicht das Richtige
- Die Nachrichten müssen in strenger Reihenfolge verarbeitet werden. Ein Beispiel sind aufeinander aufbauende Änderungen desselben Schadens, etwa ein geschätzter Schadenbetrag und eine Stunde später seine Korrektur. Wird der geschätzte Betrag aussortiert und später neu eingestellt, kommt er erst nach der Korrektur an die Reihe und überschreibt sie. Stattdessen hält der Meldedienst nach einer gescheiterten Änderung auch alle späteren Änderungen desselben Schadens zurück, bis die gescheiterte Änderung geklärt ist. Keine Änderung überholt so eine frühere. Wie das geht, beschreibt Message Ordering.
- Meldungen scheitern, weil ein Vertragssystem kurz nicht erreichbar ist. Nach drei kurz aufeinanderfolgenden Versuchen der Hauptwarteschlange landete eine solche Meldung in der Dead Letter Queue, obwohl sie gültig ist. Stattdessen wiederholt der Meldedienst den Aufruf des Vertragssystems mit Pausen, die von Versuch zu Versuch länger werden (Retry with Backoff). Ist das Vertragssystem nach einigen Minuten wieder erreichbar, verarbeitet der Meldedienst die Meldung. Die Meldung landet nicht in der Dead Letter Queue, und das Betriebsteam muss sie nicht klären.
- Das Maklerportal schickt seine Meldungen direkt an den Meldedienst statt in die Hauptwarteschlange, wartet jeweils auf die Antwort und kann eine Antwort mit Fehlergrund auswerten. Dann prüft der Meldedienst das Schadendatum sofort und weist eine Meldung ohne Schadendatum mit dem Fehlergrund „Schadendatum fehlt“ an das Maklerportal zurück. Die Meldung bleibt so beim Maklerportal, und eine Ablage für aussortierte Meldungen braucht es nicht. Das Maklerportal korrigiert die Meldung selbst und schickt sie erneut, und das Betriebsteam muss sie nicht klären.
Nachteile und typische Fehler
Die Dead Letter Queue behebt keinen Fehler. Jede aussortierte Meldung zu klären ist laufende Arbeit für das Betriebsteam, nicht nur eine Einstellung der Nachrichtenplattform. Die Dead Letter Queue enthält dieselben vertraulichen Daten wie die Hauptwarteschlange und braucht dieselben Zugriffsbeschränkungen. Die Zahl der Versuche und die Pausen dazwischen müssen eingestellt werden. Je mehr Versuche, desto länger bleibt eine fehlerhafte Meldung in der Hauptwarteschlange.
Typische Fehler und woran man sie erkennt:
- Ablage ohne Aufsicht: Niemand zählt die Meldungen in der Dead Letter Queue, und niemand ist dafür eingeteilt, sie zu klären. Die Dead Letter Queue wächst unbemerkt, und Kunden warten wochenlang auf eine Reaktion. Für den Kunden ist eine Meldung, die dort liegen bleibt, ebenso verloren wie eine gelöschte. Erkennbar ist das an einer stetig steigenden Zahl von Meldungen in der Dead Letter Queue und an Nachfragen von Kunden.
- Verdrehte Reihenfolge: Das Maklerportal schickt zu einem Schaden zwei Änderungen nacheinander: zuerst einen geschätzten Schadenbetrag, eine Stunde später eine Korrektur dieses Betrags. Die erste Änderung scheitert, weil das Vertragssystem kurz nicht erreichbar ist, und landet nach drei Versuchen in der Dead Letter Queue. Die Korrektur verarbeitet der Meldedienst ohne Fehler. Danach stellt das Betriebsteam die erste Änderung erneut ein, und der geschätzte Betrag überschreibt die Korrektur. Erkennbar ist das an Daten, die nach dem erneuten Einstellen auf einen älteren Stand zurückfallen.
- Vorübergehender Fehler aussortiert: Das Vertragssystem ist zehn Minuten lang nicht erreichbar, und der Meldedienst lehnt in dieser Zeit jede Meldung ab. Weil zu wenige Versuche oder zu kurze Pausen eingestellt sind, sind die drei Versuche einer Meldung nach wenigen Minuten verbraucht. Die Hauptwarteschlange verschiebt dann auch gültige Meldungen in die Dead Letter Queue. Erkennbar ist das an vielen aussortierten Meldungen verschiedener Absender in derselben Minute.
- Erfundene Ergänzung: Das Betriebsteam füllt ein fehlendes Pflichtfeld selbst, statt den Absender zu fragen. Das Betriebsteam trägt zum Beispiel den Tag des Eingangs als Schadendatum ein. Die Meldung wird dann ohne Fehler verarbeitet, enthält aber eine falsche Angabe. Ein erfundenes Schadendatum kann die Prüfung verfälschen, ob der Vertrag zum Schadenzeitpunkt bestand, und damit die Entscheidung über die Zahlung. Erkennbar ist das erst später, wenn diese Prüfung ein falsches Ergebnis liefert.
- Doppelter Schaden beim Neueinstellen: Der Meldedienst legt zu einer Meldung schon einen Schaden an. Danach scheitert die Verarbeitung an einem späteren Schritt, etwa weil das Vertragssystem nicht erreichbar ist, und die Meldung landet in der Dead Letter Queue. Nach dem erneuten Einstellen legt der Meldedienst einen zweiten Schaden an. Erkennbar ist das an doppelten Schäden mit derselben Meldungsnummer.
Weiterführend
Verwandte Ansätze
- Messaging: beschreibt den Austausch von Nachrichten über Warteschlangen, also die Umgebung, in der eine Dead Letter Queue gebraucht wird.
- Competing Consumers: beschreibt mehrere Empfänger, die sich eine Warteschlange teilen, eine weitere Umgebung, in der eine Dead Letter Queue gebraucht wird.
- Idempotency: Vorgehen, bei dem der Meldedienst an der Meldungsnummer erkennt, dass er zu einer erneut eingestellten Meldung schon einen Schaden angelegt hat, und legt keinen zweiten an.
Werkzeuge und Umsetzungen
- RabbitMQ: leitet Nachrichten, die abgewiesen wurden oder deren Gültigkeitsdauer abgelaufen ist, automatisch an eine festgelegte Ablage weiter.
- Apache Pulsar: verschiebt Nachrichten nach einer einstellbaren Zahl von Versuchen in ein eigenes Thema, also einen eigenen Nachrichtenkanal.
- Spring for Apache Kafka: schreibt Nachrichten, die auch nach Wiederholungen scheitern, in ein eigenes Thema der Nachrichtenplattform Kafka. Kafka selbst hat keine eingebaute Dead Letter Queue.
- Apache ActiveMQ Artemis: verschiebt Nachrichten nach der festgelegten Zahl von Zustellversuchen an eine eigene Adresse, also einen eigenen Nachrichtenkanal.
Quellen
- Bobby Woolf: Dead Letter Channel: beschreibt das Muster aus dem Buch Enterprise Integration Patterns, nach dem die Nachrichtenplattform eine nicht zustellbare Nachricht in einen eigenen Kanal verschiebt.
- Amazon Web Services: Using dead-letter queues in Amazon SQS: erläutert die Höchstzahl an Zustellversuchen, das erneute Einstellen in die ursprüngliche Warteschlange, Alarme bei neuen Einträgen und die Grenzen bei streng geordneten Warteschlangen.