Event-Driven Architecture -- Warum und wie

Unser monolithisches Bestellsystem hatte einen Endpoint, der beim Erstellen einer Bestellung synchron den Inventar-, Zahlungs-, Versand- und Benachrichtigungsservice aufrief. Wenn einer ausfiel, fiel alles aus. Event-Driven Architecture hat diese Kette durchbrochen.

Request-Response und seine Grenzen¶

Klassische Architektur: Service A ruft Service B auf, wartet auf die Antwort, dann ruft er Service C auf. Es ist einfach, geradlinig und funktioniert hervorragend, bis Service B eine Latenz von 3 Sekunden hat oder Service C komplett nicht erreichbar ist.

Im Request-Response-Modell sind Services zeitlich gekoppelt (beide müssen gleichzeitig laufen) und räumlich gekoppelt (der Aufrufer muss die Adresse des Aufgerufenen kennen). Je mehr Services in der Kette, desto fragiler das System. Ein langsames Glied verlangsamt die gesamte Kette. Ein totes Glied stoppt sie.

Was ist Event-Driven Architecture¶

Statt direkter Aufrufe publizieren Services Events – Nachrichten darüber, was passiert ist. “Bestellung erstellt.” “Zahlung eingegangen.” “Sendung verschickt.” Andere Services abonnieren Events, die sie interessieren, und reagieren asynchron darauf.

Der Bestellservice publiziert ein OrderCreated-Event. Der Zahlungsservice fängt es ab und verarbeitet die Zahlung. Der Inventarservice fängt es ab und reserviert Ware. Der Benachrichtigungsservice fängt es ab und sendet eine E-Mail. Jeder unabhängig, jeder in seinem eigenen Tempo. Wenn der Benachrichtigungsservice nicht läuft, geht die Bestellung trotzdem durch – die E-Mail wird gesendet, sobald der Service wieder verfügbar ist.

Apache Kafka als Rückgrat¶

Für Event-Driven Architecture brauchen Sie einen Message Broker – einen Ort, wohin Events fließen und von wo sie konsumiert werden. RabbitMQ ist die traditionelle Wahl für Message Queuing. Wir haben uns für Apache Kafka entschieden, weil es mehr bietet: ein verteiltes, repliziertes Log mit Retention.

# Event-Driven Architecture -- Warum und wie
Topic: orders
Partitions: 12
Replication factor: 3
Retention: 7 days

# Event schema (Avro)
{
  "type": "record",
  "name": "OrderCreated",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "customerId", "type": "string"},
    {"name": "items", "type": {"type": "array", "items": "OrderItem"}},
    {"name": "totalAmount", "type": "double"},
    {"name": "timestamp", "type": "long"}
  ]
}

Kafka löscht Nachrichten nicht nach dem Lesen – es behält sie für einen konfigurierten Zeitraum. Ein neuer Consumer kann die Historie von Anfang an lesen. Sie müssen einen Analytics-Service hinzufügen, der alle Bestellungen des letzten Monats verarbeitet? Deployen Sie ihn und setzen Sie den Offset auf den Anfang. Kein Replay nötig, kein Datenbank-Export.

Event Sourcing – Die Wahrheit liegt in den Events¶

Traditioneller Ansatz: Sie speichern den aktuellen Zustand in einer Datenbank. Event Sourcing: Sie speichern die Reihe von Events, die zum aktuellen Zustand geführt haben. Der Zustand wird durch das Abspielen von Events abgeleitet. Wie ein Hauptbuch versus ein Kontostand.

Die Vorteile sind erheblich. Vollständiger Audit Trail – Sie wissen nicht nur, was der Zustand ist, sondern warum. Temporale Abfragen – “Wie war der Bestellstatus gestern um 15:00 Uhr?” Spielen Sie Events bis zu diesem Zeitpunkt ab. Debugging – reproduzieren Sie einen Produktionsfehler, indem Sie die exakte Sequenz von Events abspielen.

Die Nachteile sind ebenfalls erheblich. Komplexität – es ist eine andere Denkweise, und viele Entwickler tun sich damit schwer. Event-Schema-Evolution – wie ändert man die Event-Struktur, ohne bestehende Consumer zu zerstören? Eventual Consistency – das Read Model kann vorübergehend inkonsistent mit dem Write Model sein.

CQRS – Lesen und Schreiben trennen¶

Command Query Responsibility Segregation – ein separates Modell für Schreibvorgänge (Commands) und Lesevorgänge (Queries). Das Write Model akzeptiert Befehle und erzeugt Events. Das Read Model aktualisiert sich aus Events und ist für Abfragen optimiert.