Zum Hauptinhalt springen
Zurück zum E-Commerce-Lexikon

Event-Driven Architecture (ereignisgesteuerte Architektur)

GrundbegriffeStufe: Intermediate

Event-Driven Architecture ist ein Softwaredesign, bei dem Systeme auf Events wie eine Preisänderung oder eine neue Bestellung reagieren, statt sich gegenseitig nach Daten abzufragen.

Image by · CC BY 4.0

Was ist Event-Driven Architecture (ereignisgesteuerte Architektur)?

Event-Driven Architecture (EDA, ereignisgesteuerte Architektur) ist ein Softwaredesign, bei dem Systeme auf Ereignisse (Events) reagieren, etwa eine Preisänderung, ein neues Produkt oder eine aufgegebene Bestellung, statt sich gegenseitig nach festem Zeitplan nach Daten zu fragen. Ein System veröffentlicht das Event, und beliebig viele andere Systeme reagieren darauf. Events laufen meist über einen Event-Broker oder eine Message Queue wie Kafka oder RabbitMQ oder werden als Webhooks direkt an ein anderes System gesendet. Der Unterschied zu einer Request-Response-API liegt in der Richtung: Bei einem REST-Aufruf fragt der Empfänger Daten ab, wenn er sie braucht, während bei EDA der Sender die Änderung ankündigt und weitermacht. Für Produktdaten heißt das: Ein Bestands- oder Preis-Update kann einen Webshop und einen Marketplace erreichen, ohne auf einen nächtlichen Batch-Export zu warten. Sieh dir an, wie der Plattform-Sync Produktänderungen von einem PIM in verbundene Shops überträgt.

Warum Event-Driven Architecture (ereignisgesteuerte Architektur) im E-Commerce wichtig ist

Onlineshops laufen mit Daten, die sich den ganzen Tag ändern: Bestand, Preise, Produktinhalte und Bestellungen. Mit geplanten Batch-Jobs kann ein Kanal bis zum nächsten Lauf ein ausverkauftes Produkt oder einen alten Preis anzeigen. Ein ereignisgesteuertes Setup sendet jede Änderung, sobald sie passiert. Die Verzögerung schrumpft also darauf, wie schnell das empfangende System sie verarbeitet. Außerdem werden Systeme entkoppelt. ERP, PIM, Webshop und Lagersoftware müssen sich nicht direkt gegenseitig aufrufen, und eine Queue hält Events zurück, während eines der Systeme offline ist. Der Preis dafür sind mehr bewegliche Teile: Du brauchst Monitoring, Regeln für Wiederholungen und einen Plan für Events, die doppelt oder in falscher Reihenfolge ankommen.

Beispiele für Event-Driven Architecture (ereignisgesteuerte Architektur)

  • 1Event: Bestand einer SKU fällt auf 0, Producer: Lagersystem, Consumer: Webshop und Marketplace-Listings setzen den Artikel auf ausverkauft.
  • 2Event: Bestellung aufgegeben, Producer: Webshop, Consumer: ERP verbucht den Verkauf, das Versandtool erstellt ein Label, das CRM aktualisiert den Kundendatensatz.
  • 3Event: Preis geändert, Producer: ERP, Consumer: PIM speichert den neuen Preis und der Preisvergleichs-Feed wird neu erzeugt.
  • 4Event: Neues Produkt angelegt, Producer: PIM, Consumer: Ein Übersetzungsjob und ein Job zur Bildskalierung starten für dieses Produkt.
Image by · CC BY 4.0

So hilft WISEPIM

  • Optionales Auto-Sync: Nachdem du ein Produkt gespeichert hast, überträgt WISEPIM die Änderung etwa 30 Sekunden später an verbundene Shops in Magento 2, Shopify, WooCommerce, Lightspeed eCom, Ecwid, CCV Shop, Kaufland, PrestaShop, ShopWired und Google Merchant Center.
  • Geplante Automationen: Führe Importe und Exporte über einen stündlichen, täglichen, wöchentlichen oder monatlichen Zeitplan-Trigger aus, wenn ein Kanal nicht jede Änderung sofort braucht.
  • Ein Produktdatensatz: Jeder Kanal liest aus denselben Produktdaten, sodass ein Event überall dieselben Werte transportiert.
  • Vorgangsverlauf: In bezahlten Plänen kannst du eine Massenänderung rückgängig machen, bevor sie sich weiter ausbreitet.

Häufige Fehler bei Event-Driven Architecture (ereignisgesteuerte Architektur)

  • Einen Event-Broker für eine einfache Verbindung zwischen zwei Systemen einsetzen, obwohl ein direkter API-Aufruf reichen würde.
  • Die Reihenfolge von Events ignorieren, sodass ein älteres Preis-Update ein neueres überschreibt.
  • Ohne Monitoring arbeiten, sodass niemand merkt, wenn sich Nachrichten stauen oder fehlschlagen.
  • Auf eine Dead-Letter-Queue verzichten, sodass Events verschwinden, die nach mehreren Wiederholungen scheitern.

Tipps zu Event-Driven Architecture (ereignisgesteuerte Architektur)

  • Mach Consumer idempotent, damit die doppelte Verarbeitung desselben Events zum gleichen Ergebnis führt.
  • Gib jedem Event einen Zeitstempel oder eine Versionsnummer, damit Empfänger veraltete Updates ignorieren können.
  • Beginne mit einem besonders wertvollen Ablauf wie Bestands-Updates, bevor du andere Daten umstellst.
  • Protokolliere pro Event eine Correlation ID, damit du eine Änderung über alle Systeme hinweg nachverfolgen kannst.

Trends rund um Event-Driven Architecture (ereignisgesteuerte Architektur)

  • Verwaltete Event-Dienste wie AWS EventBridge, Azure Event Grid und Google Cloud Pub/Sub statt selbst betriebener Broker.
  • Serverless-Funktionen, die nur laufen, wenn ein Event eintrifft.
  • Webhooks als Standardweg, über den Commerce-Plattformen Bestell- und Produktänderungen melden.
  • Event-Streams, die neben den operativen Systemen auch Analytics und AI-Agenten versorgen.

Tools für Event-Driven Architecture (ereignisgesteuerte Architektur)

  • Apache Kafka
  • RabbitMQ
  • AWS EventBridge
  • Azure Event Grid
  • Google Cloud Pub/Sub

Auch bekannt als

EDAEreignisbasierte ArchitekturNachrichtengesteuerte ArchitekturPublish-Subscribe-Architektur (Pub/Sub)

Häufige Fragen

Systeme sagen einander Bescheid, wenn etwas passiert, statt per Timer nach Änderungen zu suchen. Ein Bestandsrückgang, eine neue Bestellung oder eine Preisänderung ist ein Event, und jedes System, das sich dafür interessiert, reagiert. Der Sender muss nicht wissen, wer zuhört.

Eine REST-API arbeitet nach Request-Response: Ein System fragt ein anderes nach Daten und wartet auf die Antwort. Bei Event-Driven Architecture kündigt das System, in dem die Änderung passiert, sie an, und die Empfänger verarbeiten sie in ihrem eigenen Tempo. Viele Setups nutzen beides, zum Beispiel ein Webhook-Event, das ein System anstößt, den vollständigen Datensatz per REST abzurufen.

Ein Kunde gibt eine Bestellung auf, und der Webshop veröffentlicht ein Bestell-Event. Das ERP verbucht den Verkauf, das Lager reserviert den Bestand und das Versandtool bereitet ein Label vor, alles auf Basis desselben Events. Keines dieser Systeme muss den Webshop nach neuen Bestellungen abfragen.

Ja, über optionales Auto-Sync. Nachdem du ein Produkt gespeichert hast, überträgt WISEPIM es etwa 30 Sekunden später an verbundene Shops in Magento 2, Shopify, WooCommerce, Lightspeed eCom, Ecwid, CCV Shop, Kaufland, PrestaShop, ShopWired und Google Merchant Center. Andere Importe und Exporte laufen über den Zeitplan-Trigger einer Automation.

Bei einem kleinen Katalog mit nur einem Vertriebskanal ist ein geplanter Export oder ein direkter API-Aufruf einfacher zu bauen und zu debuggen. EDA lohnt sich, wenn mehrere Systeme dieselben Änderungen brauchen und Verzögerungen zu Überverkäufen oder falschen Preisen führen.

Noch Fragen?

Keine passende Antwort gefunden? Melde dich bei unserem Team.

Support kontaktieren

Weiter entdecken

Handverlesene nächste Schritte, um tiefer einzusteigen.