Was ist Event-Driven Architecture und wann braucht man Apache Kafka?
Direkte Antwort
Event-Driven Architecture entkoppelt Services, indem sie Zustandsänderungen als Events veröffentlichen, statt sich direkt gegenseitig aufzurufen. Apache Kafka wird notwendig, sobald mehrere Konsumenten dieselben Events zuverlässig, in hoher Reihenfolge und mit Wiederholbarkeit verarbeiten müssen — für einfache Punkt-zu-Punkt-Kommunikation zwischen wenigen Services ist ein einfacherer Message Broker oder direkte API-Aufrufe oft ausreichend.
"Ein Event-Driven-System entkoppelt, wer ein Ereignis auslöst, von wer darauf reagiert — Kafka ist dabei die Infrastruktur, nicht das Prinzip selbst.
Event-Driven Architecture wird oft mit Kafka gleichgesetzt, obwohl das Architekturprinzip unabhängig von der konkreten Technologie ist und Kafka nur eine von mehreren möglichen Umsetzungen darstellt.
Das Grundprinzip der Entkopplung durch Events
Statt dass Service A direkt Service B aufruft, veröffentlicht Service A ein Event ("Bestellung angelegt"), auf das beliebig viele Konsumenten reagieren können, ohne dass Service A davon weiß oder es explizit ansprechen muss.
Das reduziert direkte Abhängigkeiten zwischen Services erheblich, weil ein neuer Konsument einfach hinzugefügt werden kann, ohne den ursprünglichen Publisher zu verändern — ein zentraler Vorteil gegenüber synchronen Punkt-zu-Punkt-Aufrufen.
Warum Kafka mehr ist als ein Message Broker
Kafka unterscheidet sich von klassischen Message-Queue-Systemen durch persistentes, wiederholbar lesbares Event-Log, das mehreren unabhängigen Konsumentengruppen erlaubt, dieselben Events zu unterschiedlichen Zeitpunkten und in ihrem eigenen Tempo zu verarbeiten.
Diese Eigenschaft macht Kafka besonders wertvoll für Event-Sourcing-Architekturen oder wenn neue Konsumenten historische Events nachträglich verarbeiten müssen — Eigenschaften, die ein einfacherer Broker wie RabbitMQ typischerweise nicht in derselben Form bietet.
Wann der Aufwand nicht gerechtfertigt ist
Für eine überschaubare Anzahl an Services mit einfacher, synchroner Kommunikation ist der Betriebsaufwand von Kafka (Cluster-Management, Partitionierung, Consumer-Group-Koordination) oft höher als der Nutzen.
Ein einfacherer Ansatz — etwa ein leichtgewichtiger Message Broker oder direkte REST-Aufrufe mit Retry-Logik — deckt viele Fälle mit deutlich weniger operativer Komplexität ab, solange keine große Anzahl an Konsumenten oder Nachverarbeitungsbedarf für historische Events besteht. Ein Punkt, der in Kafka-Einführungen oft zu spät kommt: Kafka liefert standardmäßig At-Least-Once-Zustellung, kein Exactly-Once über Service-Grenzen hinweg — jeder Konsument muss also selbst idempotent verarbeiten (etwa über eine eindeutige Event-ID und einen Dedup-Check), sonst führt ein Consumer-Neustart nach einem Fehler zu doppelt verarbeiteten Bestellungen oder doppelten Buchungen.
Wann passt es — wann nicht?
Passt gut
- ✓Mehrere unabhängige Services müssen auf dieselben Ereignisse reagieren, teils zeitversetzt oder mit Nachverarbeitungsbedarf
- ✓Es gibt einen klaren Bedarf an Event-Sourcing oder Wiederabspielbarkeit historischer Ereignisse
Passt nicht
- ✗Es gibt nur wenige Services mit einfacher, synchroner Kommunikation