Message Queue
Eine Message Queue ist eine Warteschlange, in der Nachrichten zwischen Systemen zwischengespeichert werden, bis der Empfänger sie verarbeiten kann. Sie entkoppelt Sender und Empfänger, puffert Lastspitzen ab und sorgt dafür, dass keine Nachricht verloren geht – im ERP-Umfeld etwa Bestellungen, Bestandsänderungen oder Belege zwischen Shop, ERP und Versand.
Eine Message Queue (deutsch: Nachrichten-Warteschlange) ist ein Puffer, in dem Nachrichten zwischen zwei oder mehr Systemen zwischengespeichert werden, bis der Empfänger bereit ist, sie zu verarbeiten. Ein sendendes System – der Producer – legt eine Nachricht in die Warteschlange, ein empfangendes System – der Consumer – holt sie später ab. Beide müssen dafür nicht gleichzeitig verfügbar sein und nicht dasselbe Tempo halten. Das Prinzip ähnelt einer Poststelle mit Postfach: Der Absender wirft einen Brief ein und geht weiter; der Empfänger leert das Fach, wenn es ihm passt. Die Warteschlange arbeitet üblicherweise nach dem FIFO-Prinzip – wer zuerst eingestellt wird, wird zuerst bearbeitet.
Im ERP-Umfeld ist die Message Queue der Baustein, der einen zuverlässigen, asynchronen Datenfluss zwischen Systemen ermöglicht. Läuft eine Bestellung aus dem Onlineshop ein, während das ERP gerade mit einem Batch-Lauf beschäftigt ist, geht sie nicht verloren: Sie wartet in der Queue, bis das ERP sie abarbeitet. Genauso werden Bestandsänderungen, Belege oder Versandaufträge zwischen Shop, ERP, Marktplatz und Logistik über Warteschlangen transportiert. So bleibt jede Bestellung, jede Statusänderung und jede Buchung erhalten, auch wenn ein System kurz überlastet oder nicht erreichbar ist.
Auf einen Blick
- Message Queue = Warteschlange, die Nachrichten zwischen Systemen puffert, bis der Empfänger bereit ist
- Entkoppelt Producer (Sender) und Consumer (Empfänger): kein gleichzeitiges Verfügbarsein, kein gleiches Tempo nötig
- Arbeitet asynchron und meist nach dem FIFO-Prinzip (First In, First Out)
- Fängt Lastspitzen ab und verhindert Datenverlust bei Ausfällen oder Überlast
- Im ERP transportiert sie Bestellungen, Bestandsänderungen, Belege und Versandaufträge zuverlässig zwischen den Systemen
Wie eine Message Queue funktioniert
Eine Message Queue liegt zwischen den beteiligten Systemen und nimmt Nachrichten entgegen, statt sie direkt weiterzureichen. Der Producer schreibt eine Nachricht in die Warteschlange und erhält sofort eine Bestätigung, dass sie angenommen wurde – ohne warten zu müssen, bis der Empfänger sie tatsächlich verarbeitet hat. Die Queue hält die Nachricht vor, bis ein Consumer sie abholt. Dieser bestätigt nach erfolgreicher Verarbeitung den Empfang (Acknowledgement), woraufhin die Nachricht aus der Warteschlange entfernt wird. Bleibt die Bestätigung aus, etwa weil der Consumer abstürzt, wird die Nachricht erneut zugestellt – nichts geht verloren.
Der entscheidende Effekt ist die Entkopplung in Zeit und Last. Sender und Empfänger arbeiten unabhängig voneinander: Der Shop kann in einer Sekunde hundert Bestellungen einstellen, während das ERP sie in seinem eigenen Tempo abarbeitet. Die Warteschlange wirkt dabei wie ein Stoßdämpfer, der Spitzen glättet. Fällt der Empfänger aus, stauen sich die Nachrichten in der Queue und werden nach dem Wiederanlauf der Reihe nach zugestellt.
Producer, Consumer, Broker und Topic
Vier Begriffe kehren immer wieder: Der Producer erzeugt und sendet Nachrichten. Der Consumer empfängt und verarbeitet sie. Der Message Broker ist die Software, die die Warteschlangen verwaltet, Nachrichten speichert und ihre Zustellung überwacht – bekannte Vertreter sind RabbitMQ, Apache Kafka oder Amazon SQS. Im Publish-Subscribe-Modell tritt an die Stelle einer einzelnen Queue ein Topic, an dem sich mehrere Consumer anmelden: Eine Nachricht wird dann an alle interessierten Empfänger verteilt, statt nur von einem abgeholt zu werden. So kann eine einzige Bestellmeldung gleichzeitig Buchhaltung, Lager und Versand erreichen.
Warum eine Message Queue wichtig ist
Ohne Warteschlange müsste ein sendendes System direkt auf die Antwort des Empfängers warten (synchrone Verarbeitung). Ist der Empfänger langsam, überlastet oder nicht erreichbar, blockiert das den gesamten Ablauf – im schlimmsten Fall bricht der Vorgang ab und die Daten sind weg. Eine Message Queue löst dieses Problem, indem sie die Übergabe von der Verarbeitung trennt. Der Sender ist seine Nachricht sicher los, sobald sie in der Queue liegt; ob und wann der Empfänger sie verarbeitet, ist eine getrennte Angelegenheit.
Daraus ergeben sich handfeste Vorteile für die Zuverlässigkeit. Lastspitzen – etwa an einem Aktionstag mit vielen Bestellungen – werden abgefedert, weil die Queue als Puffer dient und das Backend nicht überrennt. Systeme lassen sich unabhängig voneinander warten und neu starten, ohne dass Nachrichten verloren gehen. Und weil jede Nachricht persistent gespeichert wird und erst nach Bestätigung verschwindet, entsteht eine belastbare „Genau-einmal“- oder „Mindestens-einmal“-Zustellung. Für ein ERP, in dem jede Bestellung und jede Buchung zählt, ist das die Grundlage sauberer Datenqualität.
Message Queue im ERP-Datenfluss
Im täglichen Betrieb transportiert die Message Queue die Ereignisse rund um das ERP. Eine Bestellung aus dem Shop wird als Nachricht eingestellt und wandert ins ERP, das den Auftrag anlegt und den Bestand bucht. Die Bestandsänderung wird ihrerseits als Nachricht verteilt und über alle Verkaufskanäle zurückgespiegelt. Versandaufträge fließen an den Logistikdienstleister, Tracking-Nummern und Statusmeldungen kommen zurück. Jeder dieser Schritte läuft asynchron über Warteschlangen, sodass kein Mitarbeiter Daten von Hand übertragen muss und kein Vorgang verloren geht, wenn ein System kurz nicht antwortet.
Message Queues sind damit ein zentraler Baustein moderner Integrationsarchitekturen. In einer ereignisgetriebenen Architektur (Event-Driven Architecture) reagieren Systeme auf Ereignisse, die über Queues und Topics verteilt werden – „Bestellung eingegangen“, „Bestand geändert“, „Sendung verschickt“. Middleware und ein Enterprise Service Bus nutzen Warteschlangen intern, um Nachrichten zwischen den angebundenen Systemen zwischenzuspeichern und zuverlässig weiterzuleiten.
Idempotenz und Dead-Letter-Queue
Weil Nachrichten in verteilten Systemen mehrfach zugestellt werden können, muss die Verarbeitung idempotent sein: Dieselbe Bestellmeldung darf nicht zweimal als getrennter Auftrag im ERP landen, wenn sie erneut ankommt. Der Consumer erkennt Duplikate über eine eindeutige Kennung und verarbeitet sie nur einmal. Nachrichten, die trotz mehrfacher Versuche nicht verarbeitet werden können – etwa wegen fehlerhafter Daten – landen in einer separaten Dead-Letter-Queue. Dort blockieren sie nicht den regulären Fluss, sind aber für Analyse und manuelle Nachbearbeitung erhalten.
Abgrenzung: Message Queue, API, Webhook und ESB
Message Queue, API und Webhook bezeichnen unterschiedliche Muster des Datenaustauschs. Eine API ist der Andockpunkt eines Systems und wird typischerweise synchron aufgerufen: Der Aufrufer stellt eine Anfrage und wartet auf die Antwort. Ein Webhook dreht die Richtung um – ein System ruft aktiv eine hinterlegte Adresse auf, sobald ein Ereignis eintritt. Beide sind auf die unmittelbare Zustellung ausgelegt. Die Message Queue setzt dagegen bewusst auf Asynchronität und Pufferung: Sie garantiert, dass die Nachricht erhalten bleibt, auch wenn der Empfänger gerade nicht bereit ist. In der Praxis ergänzen sich die Muster – ein Webhook kann eine Nachricht auslösen, die in einer Queue landet und von dort robust weiterverarbeitet wird.
Vom Enterprise Service Bus (ESB) und von Middleware unterscheidet sich die Queue durch ihren Umfang. Sie ist der reine Transport- und Puffer-Mechanismus; ESB und Middleware sind übergeordnete Schichten, die zusätzlich Formate übersetzen, Felder mappen und Abläufe orchestrieren – und dafür Message Queues als internen Baustein einsetzen. Kurz: Die Queue befördert und puffert Nachrichten, die Middleware koordiniert das inhaltliche Zusammenspiel vieler Systeme.
Message Queue bei der ERP-Auswahl
Für Anwender ist die Message Queue meist nicht direkt sichtbar – sie arbeitet im Hintergrund der Integrationsschicht. Bei der ERP-Auswahl lohnt dennoch der Blick darauf, wie ein System mit asynchroner Verarbeitung umgeht: Puffert es eingehende Bestellungen zuverlässig, auch unter Last? Werden fehlgeschlagene Vorgänge automatisch wiederholt und in einer Dead-Letter-Queue gesammelt, statt still verloren zu gehen? Wie transparent ist das Monitoring der Warteschlangen, und lassen sich hängende Nachrichten gezielt nachverarbeiten? Systeme, die sauber auf Warteschlangen aufsetzen, verkraften Lastspitzen und Teilausfälle deutlich besser.
Für den DACH-Raum ist zusätzlich relevant, wo die Nachrichten zwischengespeichert werden. Weil in den Warteschlangen personenbezogene Kunden- und Bestelldaten liegen – häufig sogar persistent, bis der Empfänger sie abholt – gelten dieselben Anforderungen der DSGVO wie für den übrigen Datenfluss. Bei cloudbasierten Message-Broker-Diensten sind Speicherort, Zugriffsschutz und Aufbewahrung der gepufferten Daten Teil der Auftragsverarbeitung und sollten vertraglich geregelt sein.
Praxisbeispiel
Beispiel: Message Queue am Aktionstag im Onlinehandel
Ein mittelständischer Onlinehändler startet eine Rabattaktion. Innerhalb weniger Minuten laufen mehrere hundert Bestellungen aus Shop und Marktplätzen ein – deutlich mehr, als das ERP im selben Moment verbuchen kann. Statt die Bestellungen direkt an das ERP durchzureichen und es damit zu überlasten, stellt die Integrationsschicht jede Bestellung als Nachricht in eine Message Queue.
Das ERP holt sich die Nachrichten aus der Warteschlange in seinem eigenen Tempo und legt die Aufträge der Reihe nach an. Die Kunden erhalten sofort ihre Bestätigung, weil die Annahme in der Queue schon als erfolgreich gilt. Als das ERP für ein Release-Update kurz neu gestartet wird, warten die in der Zwischenzeit eingegangenen Bestellungen einfach in der Queue und werden danach lückenlos abgearbeitet. Eine Bestellung mit fehlerhaften Daten landet in der Dead-Letter-Queue und wird später manuell geprüft – ohne den restlichen Fluss aufzuhalten. Kein Auftrag geht verloren, und kein Kunde bemerkt die Lastspitze.
Häufige Fragen
Passende Leistungen
Fragen zu Message Queue in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.