Mit Event Driven Architecture zu resilienten und dynamischen IT-Lösungen

Digitale Systeme müssen schnell, flexibel und resilient sein. Klassische Request-Response-Architekturen (RRA) stoßen dabei häufig auf Problemstellungen: Sie erfordern hohe Verfügbarkeit, sind stark gekoppelt und erfordern gut ausgearbeitete Konzepte für die Skalierbarkeit. Diese Limitierungen zeigen, wo alternative Architekturmuster – insbesondere die Event Driven Architecture (EDA) – klare Mehrwerte bieten.

Die EDA stellt einen Paradigmenwechsel dar: Ereignisse werden in den Mittelpunkt gestellt. Statt direkter Abhängigkeiten gilt: „In einem System findet eine Aktion statt – andere Systeme können darauf reagieren.“ Dadurch wird die Kopplung reduziert, Verfügbarkeitsanforderungen werden entschärft und Systeme lassen sich besser skalieren.

Herausforderungen klassischer Architekturen

• Starke Kopplung – Services hängen direkt voneinander ab.
• Hohe Verfügbarkeitsanforderungen – fällt ein Service aus, steht oft das Gesamtsystem still.
• Skalierungsprobleme – spontane Lastspitzen lassen sich schwer abfangen.

Wie funktioniert Event Driven Architecture

Event Driven Architecture (EDA) bedeutet, dass Systeme Ereignisse (Events) veröffentlichen, wenn etwas Relevantes passiert und andere Systeme diese Ereignisse konsumieren können, um eigenständig zu reagieren. Es gibt keinen direkten Aufruf vom Produzenten zum Konsumenten – die Kopplung erfolgt über einen Event-Broker (z. B. Kafka, SNS/SQS, RabbitMQ). Dadurch können Produzenten und Konsumenten unabhängig voneinander skaliert und weiterentwickelt werden oder auch temporär offline sein.

• Producer: erzeugt ein Event (z. B. „CustomerCreated“) und veröffentlicht es im Broker.
• Broker: speichert/verteilt Events und ermöglicht Replays sowie Skalierung.
• Consumer: abonniert relevante Events und führt daraus resultierende Aktionen aus.

Praxisbeispiel: Kundenanlage mit EDA

Nachfolgendes Schaubild zeigt eine typische EDA-Interaktion. Das Kunden-Frontend löst über eine API die Anlage eines Kunden im Customer-Management-System aus. Nach erfolgreicher Anlage wird ein Event mit den Kundendaten (first_name, last_name, email) in den Event-Broker gestellt. Unabhängige Systeme wie Billing- oder Vertragsmanagement konsumieren dieses Event und führen ihre Folgeschritte aus – ohne dass das Customer-Management sie direkt ansteuert.

Vorteil: Keine Punkt-zu-Punkt-Abhängigkeiten, bessere Resilienz und skalierbare Verarbeitung – Konsumenten können Events nachholen, falls sie kurzzeitig offline waren.

Die drei Grundpfeiler der Event Driven Architecture

Die EDA basiert auf drei fundamentalen Prinzipien:

Loose Coupling

• Services kommunizieren über Events.
• Neue Konsumenten lassen sich einfach und unabhängig hinzufügen.
• Systeme bleiben flexibel und erweiterbar.

Asynchrone Kommunikation

• Produzenten und Konsumenten müssen nicht gleichzeitig online sein.
• Events werden in Queues oder Brokern zwischengespeichert.
• Lastspitzen können zeitversetzt verarbeitet werden.

Eventual Consistency

• Daten sind nicht sofort synchron, sondern gleichen sich über Zeit ab.
• Ein bewusstes Konflikt- und Fehlermanagement ist erforderlich.
• Ermöglicht hohe Verfügbarkeit und Skalierbarkeit.

Events verstehen – mehr als nur Nachrichten

Ein Event beschreibt eine relevante Änderung in einem System.

Beispiele:

• CustomerCreated –> Ein neuer Kunde wurde angelegt im Customer-Management. Das Vertragsmanagement legt daraufhin einen neuen Vertrag für den Kunden an.
• ContractCreated –> Ein neuer Vertrag wurde vom Vertragsmanagement angelegt. Daraufhin meldet das Customer-Management-System dem Kunden die Bestätigung über eine erfolgreiche Vertragsanlage.

Naming Conventions: Events vs. Commands – was ist der Unterschied und warum ist er wichtig?

• Event:
  • Beschreibt etwas, das bereits passiert ist (Vergangenheit). Faktischer Zustand, unveränderbar.
  • Wird typischerweise „broadcasted“ – viele Konsumenten können dasselbe Event auslesen.
  • Beispiel: CustomerCreated, InvoicePaid, ContractTerminated.
• Command:
  • Fordert eine konkrete Aktion an (Imperativ, Zukunft). Absicht/Intent eines Aufrufers.
  • Adressiert typischerweise einen Empfänger/Owner.
  • Beispiel: CreateCustomer, SendInvoice, TerminateContract.

Warum zwischen Systempartnern bevorzugt Events anstelle von Commands verwendet werden

• Kopplung und Verantwortlichkeiten:
  • Commands koppeln Aufrufer an den Verantwortlichen des Fachobjekts. Events entkoppeln Produzenten von Konsumenten.
• Datenfluss und Skalierung:
  • Events ermöglichen Fan-out, Replays, Auditing und Analytics, ohne den Producer zu belasten. Commands skalieren entlang der Schreibautorität.
• Konsistenzmodell:
  • Commands ändern Zustände; Events dokumentieren Änderungen. Eventual Consistency entsteht, weil Konsumenten Änderungen zeitversetzt verarbeiten.
• Fehlertoleranz:
  • Bei Events können Konsumenten nachholen (Retry/Replay). Bei Commands muss der Aufrufer mit Timeouts/Fehlern umgehen oder eine asynchrone Kommandowarteschlange nutzen.

Vorteile von EDA im Überblick

• Flexibilität – neue Konsumenten können jederzeit angebunden werden.
• Resilienz – Ausfälle einzelner Systeme gefährden nicht das Gesamtsystem.
• Skalierbarkeit – Lastspitzen lassen sich effizient abarbeiten.
• Reaktivität – Systeme reagieren unmittelbar auf Ereignisse. 
• Modularität – Zustandsänderungen werden als Events publiziert und können von mehreren Systemen entkoppelt konsumiert und weiterverarbeitet werden