Event-Driven-Architektur und Message Queues
Eine Bestellung im Shop, eine Bestandsbuchung im Lager, eine bezahlte Rechnung in der Buchhaltung: In einer vernetzten Handelslandschaft löst jedes dieser Ereignisse eine Kette von Folgeaktionen in anderen Systemen aus. Werden diese Systeme direkt und synchron miteinander verdrahtet, entsteht ein fragiles Geflecht, in dem der Ausfall eines einzelnen Dienstes die gesamte Kette zum Stillstand bringt. Die Event-Driven-Architektur dreht dieses Prinzip um: Statt dass ein System ein anderes direkt aufruft, veröffentlicht es ein Ereignis auf einer Message Queue, und interessierte Verbraucher reagieren in ihrem eigenen Takt. Der deutsche B2B-E-Commerce hat inklusive elektronischem Datenaustausch ein Volumen von rund 1,4 Billionen Euro (ECC Köln / IFH Köln, B2B-Marktmonitor 2024) erreicht, und mit diesem Volumen steigt der Anspruch an belastbare, entkoppelte Datenflüsse. Dieser Artikel zeigt, wie Events und Message Queues entkoppelte und ausfallsichere Shop-Integrationen ermöglichen, und wie Retry, Reihenfolge und Idempotenz dabei sauber zusammenspielen. Wer den Push-Mechanismus dahinter vertiefen möchte, findet im Beitrag zu Webhooks und Polling die passende Grundlage, und unsere API-Entwicklung setzt diese Muster praktisch um.
Warum direkte Punkt-zu-Punkt-Kopplung an Grenzen stößt
Die einfachste Form der Integration ist der direkte Aufruf: Der Shop ruft beim Bestellabschluss synchron die ERP-Schnittstelle auf und wartet auf die Antwort. Solange beide Systeme schnell und verfügbar sind, funktioniert das. Doch in der Realität ist das ERP gerade im Wartungsfenster, die Datenbank unter Last oder das Netzwerk kurz gestört. In einer synchronen Kette bedeutet jeder dieser Fälle, dass die Bestellung im Shop scheitert oder hängt, obwohl der Kunde mit dem Shop selbst nichts zu tun hat. Je mehr Systeme beteiligt sind, desto schneller potenzieren sich diese Abhängigkeiten zu einem System, das nur so stark ist wie sein schwächstes Glied.
Hinzu kommt die schiere Zahl der Verbindungen. In einem durchschnittlichen Unternehmen sind über 900 Anwendungen im Einsatz, von denen nur etwa 28 Prozent überhaupt integriert sind (MuleSoft Connectivity Benchmark, 2024). Verbindet man jedes System direkt mit jedem anderen, wächst die Zahl der Schnittstellen quadratisch. Genau hier setzt die Entkopplung über eine Message Queue an: Jedes System spricht nur noch mit dem Broker, nicht mehr mit jedem Partner einzeln. Aus einem Netz aus N-mal-N-Verbindungen wird ein Hub-und-Spoke-Modell, das mit jeder weiteren Anbindung handhabbar bleibt. Die wirtschaftliche Relevanz ist erheblich, denn 81 Prozent der Befragten sehen Integrationshürden als Bremse der digitalen Transformation (MuleSoft Connectivity Benchmark, 2024).
Kopplung ist kein rein technisches Detail
Wie Event-Driven-Architektur und Message Queues funktionieren
Im Kern besteht eine ereignisgetriebene Integration aus drei Rollen. Ein Produzent (Producer) erzeugt ein Ereignis, etwa Bestellung-eingegangen, und legt es auf eine Message Queue oder ein Topic. Der Broker, also die Queue-Infrastruktur selbst, nimmt das Ereignis entgegen, speichert es dauerhaft und stellt es bereit. Ein oder mehrere Verbraucher (Consumer) lesen das Ereignis und verarbeiten es, jeder für seinen eigenen Zweck. Der entscheidende Unterschied zur direkten Kopplung ist die zeitliche und räumliche Entkopplung: Der Produzent muss nicht wissen, wer das Ereignis liest, wie viele Verbraucher es gibt oder ob diese gerade verfügbar sind.
Zwei grundlegende Verteilmuster sind gebräuchlich. Bei einer klassischen Arbeits-Queue wird jede Nachricht genau an einen aus einer Gruppe von Verbrauchern verteilt, um die Last zu teilen. Beim Publish-Subscribe-Modell erhält jeder interessierte Abonnent eine eigene Kopie des Ereignisses, sodass dasselbe Bestellereignis gleichzeitig das ERP, die Buchhaltung und die Lagerlogik erreichen kann. Welches Muster passt, hängt vom Datenfluss ab. Die Marktdynamik unterstreicht die Bedeutung dieser Bausteine: Der Markt für Message-Queue-Dienste wächst mit einer jährlichen Rate von rund 17,6 Prozent und soll von 1,41 Milliarden US-Dollar im Jahr 2024 auf etwa 1,66 Milliarden im Jahr 2025 steigen (The Business Research Company, 2025).
Producer
Das Quellsystem, etwa der Shop, veröffentlicht ein fachliches Ereignis. Es kennt nur den Broker, nicht die Empfänger, und ist nach dem Schreiben sofort wieder frei für den nächsten Vorgang.
Broker und Queue
Die Infrastruktur nimmt Ereignisse an, hält sie dauerhaft vor und puffert Lastspitzen ab. Sie entkoppelt die Geschwindigkeit der Produzenten von der Geschwindigkeit der Verbraucher.
Consumer
Das Zielsystem liest Ereignisse in seinem eigenen Takt, verarbeitet sie und bestätigt den Empfang. Fällt es aus, bleiben die Ereignisse sicher in der Queue liegen.
Arbeits-Queue
Jede Nachricht geht an genau einen Verbraucher einer Gruppe. So lässt sich Last horizontal verteilen, indem mehr Worker dieselbe Queue abarbeiten.
Publish-Subscribe
Jeder Abonnent erhält eine eigene Kopie des Ereignisses. Ein Bestellereignis kann so parallel mehrere nachgelagerte Prozesse anstoßen, ohne dass der Produzent davon weiß.
Event-Log
Manche Broker speichern Ereignisse als geordneten, nachlesbaren Strom. Neue Verbraucher können die Historie erneut lesen und so ihren Zustand aus dem Ereignisstrom wiederaufbauen.
Diese Bausteine sind nicht an ein bestimmtes Produkt gebunden. Ob ein leichtgewichtiger Broker für eine überschaubare Anbindung genügt oder ob ein verteiltes Event-Log für hohe Durchsätze nötig ist, entscheidet die Last- und Aktualitätsanforderung. Wichtiger als die Wahl des Werkzeugs ist, dass die Architektur die drei Eigenschaften Entkopplung, Pufferung und Wiederholbarkeit konsequent nutzt. Eine durchdachte Middleware bildet genau diese Schicht zwischen Shop und ERP ab.
Entkopplung und Lastpufferung als Stabilitätsgewinn
Der vielleicht größte praktische Vorteil einer Queue ist ihre Funktion als Lastpuffer. Im Handel sind Lastspitzen die Regel, nicht die Ausnahme: Eine Rabattaktion, ein Newsletter-Versand oder das Weihnachtsgeschäft können die Zahl der Bestellungen innerhalb von Minuten vervielfachen. Ein synchron angebundenes ERP müsste diese Spitze in Echtzeit verkraften, sonst bricht die Bestellannahme zusammen. Eine Queue nimmt die Ereignisse dagegen so schnell an, wie sie eintreffen, und lässt die Verbraucher sie in ihrem nachhaltigen Tempo abarbeiten. Die Spitze wird zeitlich gestreckt, statt das langsamste System zu überfahren.
Wie real dieses Risiko ist, zeigt eine Auswertung von Produktionsvorfällen: Rund 34 Prozent der ereignisgetriebenen Systeme konnten Lastspitzen jenseits des Dreifachen ihrer Grundlast nicht bewältigen (arXiv, 2025). Das klingt zunächst ernüchternd, unterstreicht aber genau den Punkt: Eine Queue allein löst das Problem nicht automatisch, sie muss bewusst auf Pufferung, Drosselung und horizontale Skalierung der Verbraucher ausgelegt sein. Richtig dimensioniert verwandelt sie eine gefährliche Spitze in eine handhabbare Welle. Gleichzeitig wächst der Bedarf an genau dieser Fähigkeit, denn nach Einschätzung von IDC werden bis 2025 rund 90 Prozent der weltgrößten Unternehmen mit Echtzeitdaten arbeiten (IDC, zitiert nach Branchenanalyse 2025).
| Eigenschaft | Direkte synchrone Kopplung | Event-Driven mit Queue |
|---|---|---|
| Ausfall eines Ziels | blockiert die gesamte Kette | Ereignisse bleiben in der Queue |
| Lastspitze | trifft Zielsystem ungebremst | wird zeitlich gepuffert |
| Neuer Verbraucher | Quellcode der Quelle ändern | Abonnent ergänzen, Quelle unberührt |
| Latenz | sofort, solange alles läuft | Sekunden, asynchron |
| Fehlerwiederholung | Aufrufer muss selbst lösen | Broker und Consumer übernehmen |
| Kopplung | eng, gemeinsame Verfügbarkeit | lose, unabhängiger Betrieb |
Die Entkopplung wirkt auch organisatorisch. Weil der Produzent nichts über die Verbraucher weiß, kann ein neuer nachgelagerter Prozess, etwa ein Reporting-Dienst oder eine Steueranbindung, als zusätzlicher Abonnent ergänzt werden, ohne dass der Shop angefasst werden muss. Diese Erweiterbarkeit ist ein wesentlicher Grund, warum sich ereignisgetriebene Ansätze in komplexen ERP-Anbindungen durchsetzen. Sie verwandeln punktuelle Integration in eine wiederverwendbare Infrastruktur.
Zustellgarantie, Retry und Dead Letter Queue
Eine Message Queue verspricht nicht, dass jede Verarbeitung beim ersten Versuch gelingt, sondern dass kein angenommenes Ereignis still verloren geht. Der pragmatische Standard ist die At-least-once-Zustellung: Ein Verbraucher liest eine Nachricht, verarbeitet sie und bestätigt erst danach den Empfang mit einem ACK oder Commit. Erst diese Bestätigung entfernt die Nachricht aus der Queue. Stürzt der Verbraucher vor der Bestätigung ab, bleibt die Nachricht erhalten und wird erneut zugestellt. Der Preis dieser Sicherheit sind mögliche Doppelzustellungen, die durch Idempotenz auf der Empfängerseite entschärft werden.
Scheitert die Verarbeitung wiederholt, etwa weil ein Zielsystem länger nicht erreichbar ist, greift eine Wiederholung mit exponentiellem Backoff. Nach dem ersten Fehlversuch wartet der Verbraucher kurz, dann zunehmend länger, ergänzt um eine zufällige Streuung (Jitter), damit nicht alle aufgestauten Nachrichten gleichzeitig erneut anlaufen und das gerade erholte System sofort wieder überlasten. Ereignisse, die auch nach allen Versuchen nicht verarbeitet werden können, wandern in eine Dead Letter Queue. Dort liegen sie sicher für eine spätere Analyse, lösen ein Alerting aus und blockieren nicht die Verarbeitung der nachfolgenden, gesunden Nachrichten.
// Vereinfachter Consumer mit ACK, Retry-Zählung und DLQ
async function handleMessage(msg, channel) {
const attempt = (msg.headers['x-attempt'] || 0) + 1;
try {
await processOrder(msg.body); // fachliche Verarbeitung
channel.ack(msg); // erst NACH Erfolg bestätigen
} catch (err) {
if (attempt >= MAX_ATTEMPTS) {
channel.publish('orders.dlq', msg, { reason: String(err) });
channel.ack(msg); // aus Haupt-Queue nehmen, in DLQ sichern
} else {
const delay = backoffWithJitter(attempt);
channel.nackWithDelay(msg, delay, { 'x-attempt': attempt });
}
}
}Bestätigen erst nach erfolgreicher Verarbeitung
Diese Mechanik macht eine ereignisgetriebene Anbindung robust gegen die Normalfälle des Betriebs, also Wartungsfenster, Deployments und kurzzeitige Störungen. Eine vertiefte Behandlung der Wiederholungslogik und der Frage, wie viele Versuche sinnvoll sind, finden Sie im Schwester-Artikel zu Idempotenz und Retry-Strategien. Dort wird auch erläutert, wie sich Backoff-Kurven an die Wiederherstellungszeit der Zielsysteme anpassen lassen.
Reihenfolge wahren: warum Sequenz im Handel zählt
In vielen Geschäftsprozessen ist die Reihenfolge der Ereignisse fachlich bedeutsam. Wird zu einer Bestellung erst eine Änderung und dann eine Stornierung gemeldet, führt eine vertauschte Verarbeitung zu einem falschen Endzustand. Ähnliches gilt für aufeinanderfolgende Bestandsbuchungen desselben Artikels oder für Statuswechsel einer Sendung. Eine naive Parallelverarbeitung über viele Verbraucher kann die ursprüngliche Reihenfolge zerreißen, weil schnellere Worker langsamere überholen.
Die übliche Lösung ist die partitionierte Reihenfolge. Statt eine globale Sortierung über alle Ereignisse zu erzwingen, was die Parallelität zunichte machen würde, werden Ereignisse anhand eines Schlüssels gruppiert. Alle Ereignisse zu einer Bestellnummer oder zu einer Artikelnummer landen in derselben Partition und werden dort streng der Reihe nach verarbeitet. Unterschiedliche Schlüssel verteilen sich auf verschiedene Partitionen und werden parallel abgearbeitet. So bleibt die Reihenfolge dort erhalten, wo sie zählt, ohne den Durchsatz insgesamt zu opfern.
- Partitionsschlüssel sorgfältig wählen: Die Bestell- oder Artikelnummer eignet sich meist gut, weil sie alle zusammenhängenden Ereignisse bündelt und gleichmäßig streut.
- Globale Ordnung vermeiden, wo sie nicht nötig ist: Eine systemweite Gesamtreihenfolge ist teuer und selten erforderlich. Reihenfolge je Geschäftsobjekt genügt in der Regel.
- Versions- oder Sequenznummer mitführen: Eine fortlaufende Nummer im Ereignis erlaubt dem Verbraucher, veraltete oder doppelte Nachrichten zu erkennen und zu verwerfen.
- Idempotenz als Sicherheitsnetz: Selbst bei korrekter Partitionierung kann eine Wiederholung ein bereits verarbeitetes Ereignis erneut liefern. Idempotente Verarbeitung fängt das ab.
Reihenfolge und Parallelität sind kein Widerspruch
Idempotenz: Doppelzustellungen folgenlos machen
Weil die At-least-once-Zustellung Doppelzustellungen ausdrücklich in Kauf nimmt, ist Idempotenz auf der Empfängerseite der entscheidende Gegenpart. Idempotent bedeutet, dass die mehrfache Verarbeitung desselben Ereignisses denselben Endzustand erzeugt wie eine einmalige Verarbeitung. Eine Bestellung darf nicht zweimal angelegt, eine Zahlung nicht zweimal verbucht und ein Lagerbestand nicht doppelt reduziert werden, auch wenn dasselbe Ereignis aus technischen Gründen zweimal ankommt.
Das praktische Mittel ist ein eindeutiger Idempotenz-Schlüssel pro Ereignis, etwa die Bestellnummer in Kombination mit dem Ereignistyp. Der Verbraucher führt eine Tabelle der bereits verarbeiteten Schlüssel und prüft jede eingehende Nachricht dagegen. Ist der Schlüssel bekannt, wird die Nachricht bestätigt, aber nicht erneut verarbeitet. Wichtig ist, dass die Prüfung und die fachliche Verarbeitung in derselben Transaktion stattfinden, damit zwischen Prüfung und Schreiben keine Lücke entsteht, in der eine zweite Zustellung durchrutschen könnte.
-- Idempotente Verarbeitung in einer Transaktion
BEGIN;
-- Schlüssel reservieren; bei Konflikt wurde das Event bereits verarbeitet
INSERT INTO processed_events (event_key)
VALUES ('order:10245:created')
ON CONFLICT (event_key) DO NOTHING;
-- Nur fortfahren, wenn der INSERT eine neue Zeile erzeugt hat
-- (sonst: Event ist ein Duplikat, Verarbeitung überspringen)
INSERT INTO erp_orders (order_no, payload)
SELECT '10245', '{...}'
WHERE EXISTS (
SELECT 1 FROM processed_events WHERE event_key = 'order:10245:created'
);
COMMIT;Idempotenz ist damit kein Zusatzfeature, sondern eine Grundbedingung jeder belastbaren ereignisgetriebenen Integration. Sie erlaubt es, die einfachere und robustere At-least-once-Zustellung zu nutzen, statt das aufwendige und über Systemgrenzen kaum erreichbare Exactly-once anzustreben. Wie sich idempotente Endpunkte konkret entwerfen lassen und welche Rolle Idempotenz-Schlüssel in REST-Schnittstellen spielen, vertieft der Beitrag zu Idempotenz und Retry-Strategien.
Praxis: ereignisgetriebene Shop-zu-ERP-Anbindung aufbauen
In einer realen Anbindung zwischen Shop und ERP existiert nicht ein Datenfluss, sondern eine Vielzahl, jeder mit eigenen Anforderungen an Aktualität, Reihenfolge und Volumen. Die Aufgabe der Integrationsschicht ist es, diese Flüsse als Ereignisse zu modellieren und über den Broker zu führen. Der typische Aufbau folgt einem klaren Muster, das sich schrittweise einführen lässt, ohne den laufenden Betrieb zu unterbrechen.
- Ereignisse fachlich schneiden: Klare, fachliche Ereignisse wie Bestellung-eingegangen oder Bestand-geändert definieren, statt technische Datenbank-Updates durchzureichen. Jedes Ereignis trägt einen eindeutigen Schlüssel.
- Annahme von Verarbeitung trennen: Der Eingang schreibt das Ereignis nur in die Queue und bestätigt sofort. Die schwere Verarbeitung Richtung ERP läuft asynchron durch Worker.
- Partitionierung festlegen: Reihenfolgekritische Flüsse wie Statuswechsel anhand der Bestellnummer partitionieren, damit die Sequenz je Bestellung erhalten bleibt.
- Idempotenz verankern: Jeder Verbraucher prüft den Idempotenz-Schlüssel und verarbeitet jedes Ereignis höchstens einmal wirksam, auch bei Doppelzustellung.
- Fehlerpfad einrichten: Retry mit Backoff und Jitter, eine Dead Letter Queue mit Alerting und ein Verfahren zur kontrollierten Wiederaufnahme nach Behebung der Ursache.
- Beobachtbarkeit sicherstellen: Queue-Tiefe, Verarbeitungsdauer und DLQ-Füllstand überwachen, um Engpässe frühzeitig zu erkennen, bevor sie zu Störungen werden.
Dieser schrittweise Ansatz erlaubt es, zuerst den kritischsten Fluss, etwa den Bestelleingang, ereignisgetrieben umzustellen und den Rest später nachzuziehen. Dass sich solche Investitionen lohnen, zeigt der Blick auf die Kostenseite: IT-Teams verbringen mehr als ein Drittel ihrer Zeit mit Integrationsprojekten, und individuelle Integrationen kosten große Unternehmen im Schnitt erhebliche Summen an jährlichem Arbeitsaufwand (MuleSoft Connectivity Benchmark, 2024). Eine wiederverwendbare, ereignisgetriebene Schicht senkt diesen wiederkehrenden Aufwand spürbar. In über 50 Integrationsprojekten (Projekterfahrung) hat sich der hier beschriebene Aufbau als belastbarer Standard bewährt. Wer den Unterschied zwischen direkter API-Kopplung und einer vermittelnden Schicht abwägen möchte, findet im Beitrag zu REST-API versus Middleware eine Einordnung.
Die Frage ist selten, ob ein System ein anderes aufrufen kann, sondern was passiert, wenn das andere System gerade nicht antwortet. Eine Queue beantwortet genau diese Frage, indem sie das Ereignis sicher aufhebt, bis der Empfänger wieder bereit ist.
Bei aller Robustheit bleibt die Reife ein Thema: Nur rund 13 Prozent der Unternehmen sehen sich bei der Einführung ereignisgetriebener Architekturen in einem ausgereiften Stadium (Branchenanalyse, 2024). Das bedeutet zugleich, dass ein sauber umgesetzter ereignisgetriebener Datenfluss ein echtes Unterscheidungsmerkmal sein kann. Eine begleitende Integrationsberatung hilft, die Reihenfolge der Umstellung an Ihren konkreten Prozessen auszurichten und die Architektur weder zu unter- noch zu überdimensionieren.