Die Wahl der Transportinfrastruktur ist entscheidend für den Erfolg einer Event-Driven Architecture. Apache Kafka hat sich als de-facto Standard für Event-Streaming etabliert, ist aber nicht die einzige Option. Dieses Kapitel gibt einen Überblick über Event-Broker und deren Auswahlkriterien.
Apache Kafka fungiert als zentraler Event-Broker zwischen Producern und Consumern. Die Kernkomponenten sind Topics (logische Event-Kanäle), Partitions (physische Aufteilung für Parallelität) und Brokers (Server-Instanzen).
Kafka bietet folgende Charakteristika für Event-Driven Systeme:
Topic: Ein Topic ist ein benannter Event-Stream,
beispielsweise order.placed.v1 für Bestellungsereignisse.
Producer publizieren Events in Topics, Consumer abonnieren Topics.
Partition: Jedes Topic ist in Partitions unterteilt. Events mit demselben Key landen in derselben Partition, wodurch die Reihenfolge garantiert wird. Partitions ermöglichen parallele Verarbeitung.
Offset: Jedes Event in einer Partition erhält eine eindeutige, aufsteigende Nummer (Offset). Consumer verwenden Offsets, um ihre Position im Stream zu verwalten.
Consumer Group: Mehrere Consumer-Instanzen können sich zu einer Gruppe zusammenschließen und die Partitions eines Topics untereinander aufteilen.
Kafka unterstützt die EDA-Prinzipien durch:
Entkopplung: Producer und Consumer kennen sich nicht direkt Skalierbarkeit: Neue Consumer können jederzeit hinzugefügt werden Resilience: Events bleiben auch bei Consumer-Ausfällen verfügbar Replay: Historische Events können erneut verarbeitet werden
# Einfaches Kafka-Setup via Docker Compose
version: '3.8'
services:
kafka:
image: confluentinc/cp-kafka:latest
environment:
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
ports:
- "9092:9092"Obwohl Kafka weit verbreitet ist, existieren verschiedene Event-Broker mit unterschiedlichen Stärken:
| Broker | Typ | Hauptmerkmale | Einsatzbereich |
|---|---|---|---|
| Apache Kafka | Log-basiert | Hoher Durchsatz, Persistierung, Replay | High-Volume Event Streaming |
| RabbitMQ | Message Queue | AMQP, komplexe Routing-Patterns | Traditionelle Message-Systeme |
| Apache Pulsar | Log-basiert | Multi-Tenancy, Geo-Replikation | Cloud-native Umgebungen |
| Amazon EventBridge | Managed Service | AWS-Integration, Schema Registry | AWS-basierte Architekturen |
| Google Cloud Pub/Sub | Managed Service | Autoscaling, globale Verfügbarkeit | GCP-basierte Systeme |
| Azure Service Bus | Hybrid | Enterprise-Integration, .NET-Fokus | Microsoft-Ökosystem |
| Apache ActiveMQ | JMS-basiert | Java-Integration, bewährt | Legacy Java-Anwendungen |
| Redis Streams | In-Memory | Sehr niedrige Latenz | Real-time Analytics |
Log-basierte Broker (Kafka, Pulsar):
Queue-basierte Broker (RabbitMQ, ActiveMQ):
Cloud-native Broker (EventBridge, Pub/Sub):
Die Wahl des richtigen Event-Brokers hängt von verschiedenen Faktoren ab:
Durchsatz und Latenz:
Persistierung und Retention:
Ordering-Garantien:
Operational Complexity:
| Aufwand | Self-Managed | Managed Services |
|---|---|---|
| Setup | Hoch (Kafka, Pulsar) | Niedrig (Cloud-Services) |
| Monitoring | Komplex | Integriert |
| Skalierung | Manuell | Automatisch |
| Backups | Selbst implementiert | Automatisch |
| Security | Selbst konfiguriert | Vorkonfiguriert |
Kosten:
Ökosystem-Integration:
Skalierungsanforderungen:
Evolution und Flexibilität:
Für den Einstieg:
Für Production-Scale:
Für spezielle Anwendungsfälle:
Die Wahl des Event-Brokers sollte nicht isoliert getroffen werden, sondern die gesamte Architektur, das Team und die Geschäftsanforderungen berücksichtigen. In vielen Fällen ist Apache Kafka aufgrund seiner Reife, Community und Tooling-Ökosystem eine sichere Wahl für Event-Driven Architectures.