Microservices & Cloud Native
Was ist Event-Driven Architecture und wann braucht man Apache Kafka?
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.
Nextise Wissen · · 7 Minuten Lesezeit
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.
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, wenn …
- 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
Ein anderer Ansatz ist nötig, wenn …
- Es gibt nur wenige Services mit einfacher, synchroner Kommunikation
Wissen allein reicht nicht — wir zeigen, wie es im Betrieb funktioniert.
Unsere Seminare verbinden die Konzepte aus dem Wissen-Hub mit konkreter Praxis. Ihr Team lernt direkt an eigenen Aufgaben — praxisnah, kompakt, sofort anwendbar.
Schulungen entdeckenLassen Sie uns über Ihr nächstes Training sprechen.
Unser Team steht Ihnen rund um die Uhr zur Verfügung und freut sich auf Ihre Anfrage. Einfach anrufen oder eine Nachricht hinterlassen – wir kümmern uns schnellstmöglich um Ihre Anfrage, ob es um eine Schulung, einen Vortrag oder eine Präsentation geht. Jetzt loslegen!
Selina Schmid
Leiterin Kodschul