EAllgemein

Event-Driven Architecture (EDA)

Systeme reagieren auf Ereignisse (Events) statt auf Polling/Batch.

Event-Driven Architecture (EDA) ist ein Architekturansatz, bei dem Software-Systeme auf Ereignisse (Events) reagieren, sobald sie auftreten – statt regelmäßig Daten abzufragen (Polling) oder in festen Intervallen zu verarbeiten (Batch). Ein Event ist dabei eine „Fach-Information“ wie „Bestellung eingegangen“, „Rechnung bezahlt“ oder „Ticket erstellt“. EDA hilft besonders wachsenden KMU, Prozesse schneller, robuster und besser skalierbar zu automatisieren.

Was bedeutet Event-Driven Architecture (EDA)?

„Event-Driven“ bedeutet: Ein Ereignis löst automatisch Folgeaktionen aus. „Architecture“ beschreibt die Art, wie Systeme und Schnittstellen aufgebaut und verbunden sind. In EDA werden Ereignisse von einem System veröffentlicht (Producer) und von anderen Systemen abonniert und verarbeitet (Consumer) – oft über Event-Broker oder Messaging-Infrastruktur.

Wie funktioniert Event-Driven Architecture (EDA)?

  • 1) Event entsteht: In einem System passiert etwas Relevantes (z. B. „Kunde hat bezahlt“).
  • 2) Event wird publiziert: Das System sendet das Event (inkl. Metadaten wie Zeit, ID, Status) an einen Kanal/Broker oder via Webhooks.
  • 3) Andere Systeme reagieren: Abonnenten verarbeiten das Event, z. B. ERP bucht Zahlung, CRM aktualisiert Status, Support erstellt Aufgabe.
  • 4) Prozesskette entsteht: Aus einem Event können weitere Events folgen („Rechnung erstellt“, „Versand beauftragt“), wodurch End-to-End-Workflows entstehen.
  • 5) Monitoring & Fehlerbehandlung: Events werden protokolliert, wiederholt (Retries) oder in Dead-Letter-Queues verschoben, wenn etwas schiefgeht.

Warum ist EDA wichtig für Automatisierung & Prozesse in KMU?

Wenn Teams wachsen, scheitern manuelle Übergaben („Bitte Slack-Nachricht an Buchhaltung“) und Polling („alle 5 Minuten prüfen, ob bezahlt wurde“) an Geschwindigkeit und Zuverlässigkeit. EDA bringt hier drei zentrale Vorteile:

  • Echtzeit statt Verzögerung: Prozesse starten sofort nach dem Ereignis, z. B. Versandfreigabe direkt nach Zahlung.
  • Entkopplung: Systeme müssen sich nicht direkt kennen. Das reduziert Integrationsaufwand und macht Änderungen leichter.
  • Skalierbarkeit: Mehr Events können parallel verarbeitet werden, ohne dass ein zentraler „Monolith“ zum Engpass wird.

Beispiele aus der Praxis

  • E-Commerce: „OrderPlaced“ löst Lagerreservierung, Rechnungserstellung und Versandlabel aus.
  • Finance: „PaymentReceived“ triggert Buchung, Mahnstopp und Statusupdate im CRM.
  • Support/Operations: „TicketCreated“ startet SLA-Timer, Routing und Benachrichtigungen.

Viele KMU starten pragmatisch mit Webhooks oder Tools wie n8n und entwickeln später Richtung „echtem“ Event-Streaming weiter. EDA ist dabei kein Selbstzweck: Sie lohnt sich besonders, wenn Prozesse über mehrere Systeme laufen, schnelle Reaktionen nötig sind und Polling/Batches zu Fehlern oder Verzögerungen führen.

Was kostet Event-Driven Architecture (EDA)?

Die Kosten hängen stark von Reifegrad und Tooling ab. Einfacher Einstieg (z. B. Webhooks + Automatisierung (Automation)-Tool wie n8n) ist oft mit niedrigen laufenden Kosten möglich, während eine skalierte Plattform (Event-Broker, Observability, Betrieb) mehr Engineering-Aufwand erfordert. Treiber sind vor allem: Anzahl integrierter Systeme, Event-Volumen, Anforderungen an Verfügbarkeit/Sicherheit und Monitoring.