Event-Driven Architektur: Warum Kafka Kaskadenfehler verhindert

LogiFlow hatte geglaubt, mit künstlicher Intelligenz die perfekte Lösung gefunden zu haben – bis die Realität einbrach. Als der Rechnungsdienst abstürzte, brachen innerhalb von Minuten weitere Dienste zusammen. Die Ursache war kein mysteriöser Fehler, sondern eine fatale Architekturentscheidung: Synchroner HTTP-Verkehr zwischen den Diensten.

Um 2:00 Uhr nachts ertönte der Pager. Der Rechnungsdienst hatte keinen Speicher mehr übrig, ausgelöst durch eine undichte PDF-Bibliothek. Doch das war erst der Anfang: Der Routingdienst reagierte mit Timeouts, gefolgt vom Trackingdienst und schließlich dem Kundenportal. Ein einziger Ausfall hatte sich wie ein Dominoeffekt durch das gesamte System gezogen.

Die Illusion der KI – und die Rückkehr zur Ingenieurskunst

Defne erkannte sofort das Problem: „Warum hängt der Routingdienst überhaupt vom Rechnungsdienst ab?“ Emre gab die peinliche Wahrheit zu: „Weil eine KI-Komponente nach jeder Routenberechnung synchron eine Rechnung angefordert hat.“ Die Dienste waren eng miteinander verknüpft – ein klassischer Fall von synchroner Kommunikation zwischen Mikroservices.

Vom Dominoeffekt zur Stabilität: Event-Driven mit Kafka

Die Lösung lag in einer grundlegenden Umstellung: Statt synchroner HTTP-Aufrufe sollten die Dienste über Domain Events kommunizieren – asynchron, entkoppelt und resilient. Apache Kafka übernimmt dabei die Rolle des zuverlässigen Vermittlers.

Der Routingdienst sendet nun ein Ereignis in den Kafka-Topic routing.events:

kafka.send({
  topic: 'routing.events',
  messages: [{
    key: truckId,
    value: JSON.stringify({
      type: 'RouteCalculated',
      truckId,
      eta,
      timestamp: Date.now()
    })
  }]
});

Der Rechnungsdienst verarbeitet die Ereignisse unabhängig und im eigenen Tempo:

consumer.run({
  eachMessage: async ({ message }) => {
    const event = JSON.parse(message.value);
    if (event.type === 'RouteCalculated') {
      await generateInvoice(event);
    }
  }
});

Fällt der Rechnungsdienst aus, werden die Ereignisse einfach zwischengespeichert. Sobald er wieder verfügbar ist, verarbeitet er die Warteschlange – ohne dass andere Dienste beeinträchtigt werden. Kein Dominoeffekt. Keine nächtlichen Alarme.

Synchrone vs. asynchrone Kommunikation: Wo liegt der Unterschied?

| Synchron (HTTP) | Asynchron (Events) | |----------------------|------------------------| | Der Aufrufer wartet auf eine Antwort | „Fire and Forget“ – kein Warten | | Fehler breiten sich aus | Fehler bleiben isoliert | | Starre Kopplung der Dienste | Lose Kopplung möglich | | Einfach zu verstehen | Erfordert Schema-Design | | Ideal für 2–3 Dienste | Unverzichtbar für 10+ Dienste |

Drei Learnings aus Episode 13

• Lose Kopplung priorisieren: Dienste sollten sich nicht gegenseitig blockieren. Asynchrone Kommunikation verhindert Kettenreaktionen.

• Domain Events nutzen: Statt direkter Aufrufe kommunizieren Dienste über klare Ereignisse wie RouteCalculated oder InvoiceGenerated.

• Dead Letter Queue einrichten: Gescheiterte Nachrichten gehören nicht in den digitalen Nirgendwo. Eine separate Warteschlange ermöglicht Analyse und Nachverarbeitung.

Fazit: Architektur entscheidet über Systemstabilität

Die Geschichte von LogiFlow zeigt: Technologie allein löst keine Probleme – Architektur tut es. Künstliche Intelligenz kann Prozesse optimieren, aber nur eine durchdachte Infrastruktur verhindert Systemausfälle. Wer in einer vernetzten Welt stabil arbeiten will, kommt an Event-Driven Architecture mit Kafka nicht vorbei. Die nächste Episode dieser Reihe widmet sich dem Technical-Debt-Score – ein Werkzeug zur Messung und Steuerung technischer Schulden. Bleiben Sie dran.