Kafka & Event Streaming

Kafka ist ein hervorragendes Werkzeug – und eines der am häufigsten ohne Not eingesetzten. Ereignisgetriebene Architektur ist eine Entwurfsentscheidung mit Folgekosten, kein Häkchen auf der Technologie-Liste.

Ich helfe Ihnen bei der Einordnung vor der Einführung: Wo tragen Events Ihre Architektur wirklich – und wo reicht eine Queue, eine Outbox-Tabelle oder ein simpler Scheduler für einen Bruchteil der Betriebskomplexität?

Worüber wir sprechen

Die Bausteine – kurz und ohne Buzzword-Nebel:

Topics: Log statt Briefkasten

Kafka ist keine klassische Queue, sondern ein verteiltes, dauerhaftes Ereignis-Log: Nachrichten werden beim Lesen nicht gelöscht, sondern bleiben geordnet liegen. Mehrere Systeme können denselben Datenstrom unabhängig und je in ihrem Tempo lesen – auch rückwirkend. Das ist die eigentliche Stärke, nicht "Nachrichten verschicken".

Producer & Consumer

Erzeuger schreiben Ereignisse, Verbraucher lesen sie – entkoppelt in Zeit und Last. Consumer-Gruppen verteilen die Arbeit, Partitionen bestimmen Reihenfolge und Parallelität. Genau hier entstehen die typischen Entwurfsfehler: falsche Partitionierungsschlüssel, ungeklärte Reihenfolge-Garantien, fehlende Idempotenz.

Event-Contracts & Schemata

Ein Ereignis ist eine öffentliche Schnittstelle – mit Schema, Versionierung und Kompatibilitätsregeln, sonst zerbricht die Entkopplung beim ersten Feld-Umbau. Event-Contracts gehören für mich in jede Zielarchitektur, unabhängig davon, ob am Ende Kafka, eine Queue oder eine Datenbank die Ereignisse transportiert.

Die Folgekosten

Broker-Betrieb, Monitoring, Offset-Verwaltung, Dead-Letter-Strategien, Replays, Eventual Consistency im Fachprozess – und Fehlersuche über asynchrone Grenzen hinweg. Diese Rechnung gehört auf den Tisch, bevor die erste Nachricht fließt. Sie fällt für ein kleines Team anders aus als für eine Plattform-Organisation.

Wann Kafka – und wann etwas Einfacheres

Kafka bzw. Event Streaming trägt, wenn:

  • Mehrere unabhängige Abnehmer denselben Datenstrom brauchen – heute drei, morgen fünf, ohne dass der Erzeuger sie kennen muss
  • Die Historie selbst Wert hat: Ereignisse nachspielen, Read Models neu aufbauen, Auswertungen direkt auf dem Ereignisstrom
  • Dauerhaft hoher Durchsatz mit Lastspitzen entkoppelt werden muss – nicht nur der nächtliche Import
  • Eine Organisation dahintersteht, die Broker, Schemata und Consumer-Disziplin dauerhaft betreiben kann – oder das bewusst als Managed Service einkauft

Oft reicht – und ist dann die bessere Architektur:

  • Eine Message Queue (z. B. RabbitMQ, ActiveMQ, SQS), wenn es um Arbeitsverteilung geht: eine Nachricht, ein Bearbeiter, fertig
  • Eine DB-Outbox mit Relay, wenn Ereignisse transaktionssicher mit der Fachlogik entstehen sollen – dieselbe Datenbank, keine neue Infrastruktur, kein verlorenes Ereignis
  • Ein Scheduler oder Batch-Job, wenn "asynchron" in Wahrheit "alle fünf Minuten" bedeutet – vieles, was als Streaming-Projekt startet, ist fachlich ein Abgleich
  • Ein synchroner API-Aufruf, wenn der Aufrufer das Ergebnis ohnehin sofort braucht – Asynchronität, die fachlich niemand will, erzeugt nur Wartelogik

Meine Faustregel: Erst der Fachprozess, dann das Konsistenzmodell, zuletzt die Technologie. Wer die Reihenfolge umdreht, baut Infrastruktur für ein Problem, das er noch nicht verstanden hat. Und wer mit der Outbox startet, kann später immer noch auf Kafka wechseln – die Event-Contracts bleiben dieselben.

Woher meine Einschätzung kommt

  • Zusammenhängende Abläufe über mehrere Komponenten: In einer Payroll-Plattform habe ich Prozesse über Webanwendung, lokalen Client, Windows-Dienst und Server koordiniert. Der fachliche Abschluss hängt vom konsistenten Zusammenspiel dieser Komponenten ab. Diese Integrationserfahrung ist von einer konkreten Kafka-Referenz zu unterscheiden.
  • Event-Contracts als Handwerk: API- und Event-Contracts sind fester Bestandteil meiner Zielarchitektur-Arbeit – inklusive Ownership, Versionierung und der Frage, was passiert, wenn ein Ereignis doppelt oder gar nicht ankommt
  • Workflow- und Zuverlässigkeits-Praxis: In meiner eigenen Plattform laufen wiederaufsetzbare Temporal-Workflows und geplante Ingest-Strecken (RSS, E-Mail-Postfächer) mit Deduplizierung – dieselben Fragen nach Wiederholbarkeit, Idempotenz und Fehlerpfaden wie im Event Streaming, täglich im eigenen Betrieb
  • Integrationserfahrung aus 25+ Jahren: XML/SOAP-, HL7- und DATEV-nahe Schnittstellen, Alt-Systeme und gewachsene Datenflüsse – ich weiß, wie Datenströme zwischen Systemen in der Realität aussehen, nicht nur auf dem Whiteboard

Und die ehrliche Grenze dazu: Ich habe keine großen Kafka-Cluster über Jahre betrieben und trete nicht als Kafka-Betriebsspezialist auf. Meine Rolle ist die Architekturentscheidung davor und das Systemdesign darum herum – Konsistenzmodell, Contracts, Fehlerpfade, Idempotenz. Genau diese Entscheidungen bestimmen, ob ein Event-System trägt oder zur Dauerbaustelle wird.

Verwandte Themen: API-Strategie für die synchrone Seite Ihrer Schnittstellen und Problemklärung & Lösungsarchitektur für den Weg vom Fachprozess zur tragfähigen Architektur.

Kafka – ja oder nein?

Bringen Sie Ihren Anwendungsfall mit. Sie bekommen eine ehrliche Einordnung –
auch wenn die Antwort "eine Outbox-Tabelle reicht" lautet. Unverbindlich, 30 Minuten, kostenfrei.

Erstberatung vereinbaren (30 Min., kostenfrei)