Event-Driven Architektur: Vom Monolith zu reaktiven Systemen

Ihr Monolith funktioniert. Bestellungen werden verarbeitet, Zahlungen gehen durch, Kunden erhalten ihre E-Mails. Aber jedes Mal, wenn Sie ein neues Feature hinzufügen wollen, dauert es Monate. Jedes Deployment ist ein Albtraum. Und wenn ein Service ausfällt, fällt alles aus. Dies ist die Geschichte, wie man da rauskommt — und warum Event-Driven Architektur nicht nur ein Buzzword ist, sondern ein produktionserprobtes Pattern.

Warum die synchrone Welt nicht ausreicht¶

Traditionelle monolithische Architektur funktioniert nach dem Request-Response-Prinzip. Service A ruft Service B auf, wartet auf eine Antwort, dann ruft er Service C auf. Alles ist synchron, eng gekoppelt und abhängig von der Verfügbarkeit jeder Komponente in der Kette. Es funktioniert — bis das System wächst.

Probleme zeigen sich auf drei Ebenen. Erstens, zeitliche Kopplung: alle Services müssen gleichzeitig online sein. Zweitens, Skalierbarkeit: Sie können einen Teil des Systems nicht unabhängig skalieren. Und drittens, Weiterentwickelbarkeit: eine Änderung in einem Service kaskadiert zu allen, die davon abhängen.

Event-Driven Architektur (EDA) löst diese Probleme mit einem fundamental anderen Ansatz. Statt „aufrufen und warten” sagt sie: „etwas ist passiert — wer sich dafür interessiert, kann darüber lesen.” Ein Producer emittiert ein Event und weiß weder, noch muss er wissen, wer es konsumiert. Consumer lesen Nachrichten in ihrem eigenen Tempo. Lose gekoppelt, asynchron, resilient.

Apache Kafka als System-Backbone¶

Kafka ist nicht eine Message Queue. Es ist ein verteiltes Commit Log — ein persistenter, geordneter, replizierbarer Datensatz von allem, was im System passiert ist. Events werden nach dem Lesen nicht gelöscht. Sie bleiben im Log gemäß der konfigurierten Retention Policy.

Kafka Producer — Java-Beispiel¶

`// Kafka Producer — Senden eines OrderCreated Events

Properties props = new Properties();

props.put(“bootstrap.servers”, “kafka-1:9092,kafka-2:9092”);

props.put(“key.serializer”, StringSerializer.class);

props.put(“value.serializer”, KafkaAvroSerializer.class);

props.put(“schema.registry.url”, “http://schema-registry:8081”);

props.put(“acks”, “all”);

props.put(“enable.idempotence”, “true”);

var producer = new KafkaProducer<>(props);

var event = OrderCreated.newBuilder()

.setOrderId("ORD-2026-00142")

.setCustomerId("CUST-8837")

.setAmount(new BigDecimal("24990.00"))

.setCurrency("CZK")

.setTimestamp(Instant.now())

.build();

producer.send(new ProducerRecord<>(

"orders.created", event.getOrderId(), event

));`

Event Sourcing und CQRS¶

Event Sourcing — Die Wahrheit lebt in Events¶

Im traditionellen Ansatz speichern Sie den aktuellen Zustand: Die Bestellung hat den Status „bezahlt.” Bei Event Sourcing speichern Sie die Sequenz von Events, die zu diesem Zustand geführt haben: OrderCreated → PaymentReceived → OrderConfirmed. Der aktuelle Zustand ist abgeleitet.

Die Vorteile sind erheblich. Sie haben einen vollständigen Audit Trail. Sie können die Historie wiedergeben und den Systemzustand zu jedem Zeitpunkt rekonstruieren. Und Sie können neue Projektionen über bestehende Daten erstellen ohne Datenbank-Migrationen.

CQRS — Lesen und Schreiben trennen¶

Command Query Responsibility Segregation trennt das Schreibmodell (Commands, die den Zustand ändern) vom Lesemodell (Queries, die den Zustand lesen). Kombiniert mit Event Sourcing bedeutet das: Commands produzieren Events in Kafka, und Lesemodelle sind materialisierte Views, optimiert für spezifische Abfragen.

Saga Pattern — Verteilte Transaktionen¶

In einem Monolith haben Sie Datenbanktransaktionen. In einem verteilten System nicht. Das Saga-Pattern adressiert verteilte Konsistenz als Sequenz lokaler Transaktionen, wobei jeder Schritt eine definierte Kompensationsaktion bei Fehler hat.

Zwei Ansätze: - Choreographie: Jeder Service reagiert auf Events und publiziert eigene. Dezentralisiert, einfach für kleine Sagas. - Orchestrierung: Ein zentraler Orchestrator steuert die Schrittsequenz. Klarer, besseres Monitoring.

In der Praxis bevorzugen wir für Enterprise-Systeme die Orchestrierung.

Dead Letter Queues — Wenn Events fehlschlagen¶

In einem verteilten System werden Events fehlschlagen. Eine Dead Letter Queue (DLQ) ist ein Topic, wohin Events nach einer konfigurierten Anzahl fehlgeschlagener Verarbeitungsversuche verschoben werden.

• Retry-Strategie: Exponentieller Backoff mit Jitter
• DLQ-Monitoring: Alert bei jedem Event in der DLQ
• Reprocessing: Tooling zum Replay aus der DLQ nach einem Bugfix

Schema Registry: Avro vs Protobuf¶

Schema Registry stellt sicher, dass Producer und Consumer sich auf das Nachrichtenformat einigen — und dass Schema-Evolution bestehende Consumer nicht bricht.

Apache Avro¶

Native Integration mit dem Kafka-Ökosystem. Ideal für Kafka-first-Architekturen.

Protocol Buffers¶

Starke Typisierung, exzellente Code-Generierung. Besser für polyglotte Umgebungen mit gRPC.

Echtzeit-Analytics auf dem Event Stream¶

Eine der größten Stärken der Event-Driven Architektur: Echtzeit-Analytics direkt über den Event Stream — ohne Batch-ETL-Prozesse.

Typischer Stack: Kafka → Kafka Streams oder Apache Flink → ClickHouse oder Apache Druid → Grafana.

Praktische Use Cases: Fraud Detection, Bestandsverfolgung, Business-KPIs in Echtzeit, automatisierte Anomalie-Erkennung.

Fazit: Events sind die neue Source of Truth¶

Event-Driven Architektur verändert, wie wir über Daten und Kommunikation zwischen Services denken. Statt geteilter Datenbanken haben wir geteilte Events. Statt synchroner Ketten haben wir asynchrone reaktive Systeme. Statt „aktuellem Zustand” haben wir vollständige Historie.

Aber Vorsicht: EDA ist keine Wunderwaffe. Sie bringt eigene Komplexität mit — Eventual Consistency, verteiltes Debugging, Schema-Management, Ordering-Garantien. Der Schlüssel zum Erfolg ist ein pragmatischer Ansatz: Beginnen Sie mit einem Bounded Context, beweisen Sie den Wert, dann skalieren Sie.