Kafka und Event-Driven Architecture

In diesem Artikel möchte ich eine Einführung in die ereignisgesteuerte Architekturen (Event-Driven Architecture, kurz EDA) geben und kurz über die Vorteile sowie die Herausforderungen aus meinen Erfahrungen in realen Projekten schreiben.

In weiteren Artikeln werde ich tiefer in das Thema einsteigen und ein fiktives Projekt im Bauwesen mithilfe der EDA erstellen.

Was ist Event-Driven Architecture?

Die Event-Driven Architecture ist ein Paradigma, das die Ereignisse innerhalb verteilter Systeme in den Vordergrund stellt. Ereignisse (Events) sind innerhalb eines Systems entstandene Fakten, können Daten tragen und dienen als Auslöser (Notification).

Die Unterschiede zu einer gewöhnlichen Architektur (Request-Response) lassen sich an einem Beispiel darstellen:
Die Baugenossenschaft BayBau AG arbeitet mit Bauunternehmen zusammen und beauftragt diese mit diversen Aufgaben. Für eine vorgesehene Fassadensanierung sollen von diesen Firmen Angebote eingeholt werden.

Remote Procedure Invocation Pattern (RPI)

In einer nach RPI¹ entworfenen Systemlandschaft würde eine vereinfacht dargestellte Kommunikation zwischen den Services folgendermaßen ausschauen:

Die synchrone Kommunikation erfolgt über REST bzw. gRPC.

1. Im Frontend werden die Daten für einen Auftrag erfasst und abgeschickt
2. Das AuftragService speichert diese Daten und fordert das AngebotService auf, Angebote von Firmen einzuholen
3. Das AngebotService fragt das FirmaService ab, holt die notwendigen Firmendaten und erstellt formelle Angebotsanfragen
   An dieser Stelle ignorieren wir einfachheitshalber das Notifizieren der Firmen. Sie können in der Plattform einsteigen und sehen ihre Anfragen.
4. Das AngebotService bestätigt das erfolgreiche Erstellen der Angebotsanfragen

Vorteile

• Einfach und vertraut
• Implementierung ist leicht

Nachteile

• stark gekoppelte Services
• Ausfall eines Services bedeutet oft ein Gesamtausfall des Systems
• neue Anforderungen bedeuten Anpassungen an bestehenden Services

Event-Driven Architecture

In der Event-Driven² Variante kommunizieren die Services über Nachrichten, die in Kafka gespeichert werden, miteinander. Das AuftragService erstellt ein Event AuftragErfasst, das dem AngebotService als eine Art Benachrichtigung dient.

Das Event AuftragErfasst beinhaltet einige der notwendigen Informationen, z.B. Art der Leistung, Umfang und den Fertigstellungszeitraum. Um die Angebotsanfragen erstellen zu können, fehlen dem AngebotService noch die notwendigen Daten über die Firmen. Diese Daten werden vom FirmaService abgefragt. Aber keine Sorge. Das ist nur vorübergehend so gelöst. Durch eine Kundenanforderung wird später auch das FirmaService notwendigerweise auf Event-Driven umgestellt.

Vorteile

• lose Kopplung
• Ausfall von AngebotService hat keine Auswirkungen auf AuftragService und umgekehrt
• einfache Erweiterbarkeit wie wir in einem späteren Blogartikel sehen werden

Nachteile

• höhere Komplexität durch ein Fremdsystem (Kafka)
• Reihenfolge der Event-Kommunikation bei komplexen Systemen
• Integrationstests nicht mehr leicht durchführbar
• Zwischenzeitlich keine Konsistenz der Daten (eventually consistent)

Was sollte ich nun wählen?

Wie bei jedem Paradigma gibt es viele Vorteile aber auch Nachteile. Obwohl EDA in vielen Szenarien vorteilhaft sein kann, ist sie keine universelle Lösung. In manchen Fällen kann die Verwendung von EDA eine unnötige Komplexität und Overhead einführen.

Die Architektur sollte man immer nach voraussichtlichem Mehrwert für Business auswählen. Ein Monolith, der seine Arbeit zuverlässig erledigt und dabei leicht wartbar ist, kann genauso gut sein wie eine Systemlandschaft aus etlichen Microservices, die miteinander über synchrone Schnittstellen kommunizieren und kaum Ausfälle haben.

Betrachtet man allerdings die Daten eines Unternehmens als wertvolle Ressource, wird es notwendig auf Änderungen in Echtzeit zu reagieren, neue Use-Cases aus diesen Daten zu generieren und flexibel zu bleiben, um auf neue Entwicklungen im täglichen Geschäft schnell reagieren zu können.

EDA kann hierbei ihre Stärken ausspielen und einen echten Mehrwert bieten.

Warum so denglisch?

Abgesehen von technischen Fachausdrücken sind wahrscheinlich die Service- und Event-Namen aufgefallen. Dazu findest du im nächsten Artikel einige Informationen und die Begründung dahinter.