Ein Kunde bestellt in einem Webshop eine Kaffeemaschine. Aus diesem einen Klick folgen Dutzende Aufgaben: Das Lager muss reservieren, die Buchhaltung eine Rechnung erzeugen, der Versand ein Etikett drucken, das Marketing die Empfehlungen aktualisieren und das Controlling den Tagesumsatz hochzählen. Früher rief der Shop jedes dieser Systeme einzeln an. Fiel eines aus, hakte die ganze Kette.

Apache Kafka löst dieses Problem auf eine Weise, die zunächst unspektakulär klingt: Der Shop schreibt nur noch eine Nachricht – „Bestellung 4711 eingegangen“ – in ein gemeinsames, dauerhaft gespeichertes Protokoll. Alle anderen Systeme lesen daraus, jedes in seinem eigenen Tempo. Aus dieser einfachen Idee ist eine der wichtigsten Infrastrukturkomponenten für Datenströme geworden.

Was Apache Kafka ist und woher es kommt

Kafka ist eine verteilte Event-Streaming-Plattform. Ein Ereignis (Event) ist eine Tatsache, die zu einem bestimmten Zeitpunkt passiert ist: eine Bestellung, ein Seitenaufruf, ein Messwert eines Sensors, eine Kontobuchung. Kafka nimmt solche Ereignisse entgegen, speichert sie in fester Reihenfolge und stellt sie beliebig vielen Empfängern bereit.

Entstanden ist Kafka bei LinkedIn. Das Unternehmen brauchte eine Möglichkeit, Aktivitätsdaten von Millionen Nutzerinnen und Nutzern zuverlässig zwischen vielen Systemen zu verteilen. 2011 wurde Kafka als Open Source veröffentlicht, kurz darauf übernahm die Apache Software Foundation das Projekt. Geschrieben ist es überwiegend in Java, kleinere Teile noch in Scala, die Lizenz ist die Apache License 2.0. Mehrere Entwickler aus dem ursprünglichen Team gründeten später die Firma Confluent, die eine kommerzielle Plattform und einen Cloud-Dienst rund um Kafka anbietet und seit März 2026 zu IBM gehört.

Der Name ist eine Hommage an den Schriftsteller Franz Kafka.

Wie Kafka arbeitet: Log, Topic, Partition

Das Herzstück von Kafka ist ein Log: eine Liste, an die neue Einträge nur hinten angehängt werden. Nichts wird überschrieben, jeder Eintrag erhält eine fortlaufende Nummer, den Offset. Wer liest, merkt sich einfach, bis zu welchem Offset er gekommen ist.

Producer, Topics und Broker

• Producer sind Anwendungen, die Ereignisse schreiben, etwa der Webshop.
• Ereignisse landen in einem Topic, einer benannten Kategorie wie bestellungen oder sensordaten.
• Jedes Topic ist in Partitionen aufgeteilt. Eine Partition ist ein eigenes Log. Über einen Schlüssel – zum Beispiel die Kundennummer – sorgt Kafka dafür, dass alle Ereignisse eines Kunden in derselben Partition und damit in der richtigen Reihenfolge landen.
• Die Partitionen liegen auf mehreren Servern, den Brokern, die zusammen einen Cluster bilden. Jede Partition wird auf mehrere Broker kopiert (Replikation). Fällt ein Server aus, übernimmt eine Kopie.

Consumer und Consumer-Gruppen

Consumer lesen Ereignisse aus Topics. Mehrere Consumer können sich zu einer Consumer-Gruppe zusammenschließen und teilen sich dann die Partitionen: Hat ein Topic zwölf Partitionen, können bis zu zwölf Instanzen einer Anwendung parallel arbeiten. Wird es eng, startet das Team weitere Instanzen.

Der entscheidende Unterschied zu einer klassischen Warteschlange: Ein gelesenes Ereignis verschwindet nicht. Die Buchhaltung, das Lager und das Analyse-Team lesen dasselbe Topic unabhängig voneinander, jedes mit eigener Gruppe und eigenem Offset. Wie lange Kafka Daten aufbewahrt, legt das Team pro Topic fest – sieben Tage sind die Voreinstellung, möglich sind auch Monate oder unbegrenzte Speicherung. Alternativ behält die Log Compaction nur den jeweils neuesten Eintrag pro Schlüssel, etwa den aktuellen Lagerbestand je Artikel.

Angenommen, ein neues Reporting-System soll die Bestellungen der letzten Woche auswerten. Es setzt seinen Offset einfach an den Anfang und liest die Historie nach, ohne dass der Shop davon etwas merkt. Diese Fähigkeit, Ereignisse erneut abzuspielen, macht Kafka für Datenintegration so wertvoll.

Von ZooKeeper zu KRaft: der größte Umbau der letzten Jahre

Ein Kafka-Cluster muss wissen, welche Broker existieren, welche Partition wo liegt und welcher Broker gerade für eine Partition zuständig ist. Diese Metadaten verwaltete jahrelang ein separates System: Apache ZooKeeper. Für Betriebsteams hieß das, zwei verteilte Systeme mit eigener Konfiguration, eigenem Monitoring und eigenen Fehlerbildern zu betreiben.

Mit KRaft (kurz für Kafka Raft, nach dem Konsensverfahren Raft) verwaltet Kafka seine Metadaten inzwischen selbst. Einige Knoten übernehmen die Rolle von Controllern und speichern die Metadaten in einem internen Log. Das vereinfacht den Betrieb und erlaubt Cluster mit deutlich mehr Partitionen. Produktionsreif für neue Cluster war KRaft ab Version 3.3, mit Kafka 4.0 (2025) wurde die ZooKeeper-Unterstützung vollständig entfernt. Wer noch einen älteren Cluster mit ZooKeeper betreibt, muss vor dem Sprung auf 4.x über eine 3.x-Version migrieren, als Brücke dient Version 3.9. Anleitungen in älteren Tutorials, die zuerst ZooKeeper starten, sind damit überholt.

Erste Schritte: Kafka lokal ausprobieren

Für einen ersten Test genügt ein Rechner mit Java oder Docker. Das offizielle Projekt stellt ein Container-Image bereit:

# Kafka als einzelnen Knoten im KRaft-Modus starten
docker run -d --name kafka -p 9092:9092 apache/kafka:latest

Alternativ lässt sich das heruntergeladene Archiv direkt verwenden. Seit KRaft muss der Speicher einmalig mit einer Cluster-ID formatiert werden:

# Einmalig: Cluster-ID erzeugen und Speicher formatieren
KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
bin/kafka-storage.sh format --standalone -t "$KAFKA_CLUSTER_ID" -c config/server.properties

# Broker starten (ohne ZooKeeper)
bin/kafka-server-start.sh config/server.properties

In einem zweiten Terminal legen Sie ein Topic an, schreiben Ereignisse und lesen sie wieder aus:

# Topic mit drei Partitionen anlegen
bin/kafka-topics.sh --create --topic bestellungen --partitions 3 \
  --bootstrap-server localhost:9092

# Ereignisse zeilenweise eingeben (Beenden mit Strg+C)
bin/kafka-console-producer.sh --topic bestellungen --bootstrap-server localhost:9092

# Alle Ereignisse von Anfang an lesen, als Mitglied der Gruppe "reporting"
bin/kafka-console-consumer.sh --topic bestellungen --from-beginning \
  --group reporting --bootstrap-server localhost:9092

In echten Anwendungen schreiben und lesen Programme über Client-Bibliotheken, die es für Java, Python, Go, .NET, Node.js und viele weitere Sprachen gibt.

Kafka Streams, Connect und Flink: Daten unterwegs verarbeiten

Kafka transportiert und speichert Ereignisse. Für die Verarbeitung gibt es mehrere Bausteine:

• Kafka Connect verbindet Kafka mit Datenbanken, Data Warehouses, Cloud-Speichern oder Suchsystemen. Fertige Konnektoren übernehmen etwa Change Data Capture: Jede Änderung in einer Datenbanktabelle wird automatisch zu einem Ereignis.
• Kafka Streams ist eine Java-Bibliothek, mit der Anwendungen Datenströme filtern, umwandeln, verknüpfen und über Zeitfenster aggregieren. Ein Beispiel: Umsatz pro Filiale in Fünf-Minuten-Fenstern. Kafka Streams läuft innerhalb der eigenen Anwendung, ein separater Cluster ist nicht nötig.
• Apache Flink ist ein eigenständiges Stream-Processing-System, das häufig zusammen mit Kafka eingesetzt wird, wenn Berechnungen komplexer werden oder SQL auf Datenströmen gewünscht ist. Für Auswertungen großer Datenbestände in Batches kommt oft Apache Spark hinzu.

Wichtig für die Einordnung: Kafka selbst ist keine Analyseplattform und keine Datenbank für beliebige Abfragen. Es ist das Rückgrat, über das Daten zwischen Systemen fließen.

Kafka oder klassischer Message Broker?

Die häufigste Frage in Architekturdiskussionen lautet: Kafka oder RabbitMQ (beziehungsweise ein Cloud-Dienst wie Amazon SQS oder Azure Service Bus)? Beide verschicken Nachrichten, sie verfolgen aber unterschiedliche Modelle.

Für eine Anwendung, die gelegentlich E-Mails verschickt oder Hintergrundjobs verteilt, ist Kafka oft überdimensioniert. Eine Warteschlange erledigt das einfacher. Kafka spielt seine Stärken aus, wenn viele Systeme dieselben Ereignisse brauchen, wenn hohe Datenmengen anfallen oder wenn die Historie selbst wertvoll ist. Die Grenzen verschwimmen allerdings: Seit Version 4.2 sind die „Queues for Kafka“ (sogenannte Share Groups) produktionsreif. Damit bekommt Kafka auch Warteschlangen-Semantik, bei der sich mehrere Consumer einzelne Nachrichten teilen.

Typische Einsatzfelder

• Datenintegration: Statt Dutzender Punkt-zu-Punkt-Schnittstellen schreiben Systeme ihre Änderungen nach Kafka, andere abonnieren sie. Das entkoppelt Teams und Systeme.
• Event-getriebene Architekturen: Microservices kommunizieren über Ereignisse statt über direkte Aufrufe. Wie das bei der ausfallsicheren Bestellverarbeitung im E-Commerce aussehen kann, beschreibt unsere Infothek. Eng verwandt ist das Muster Event Sourcing, bei dem der Zustand einer Anwendung vollständig aus Ereignissen rekonstruiert wird.
• IoT und Industrie: Maschinen und Sensoren liefern laufend Messwerte. Kafka puffert sie, verteilt sie an Überwachung, Archiv und Auswertung.
• Logs und Metriken: Protokolle vieler Server werden zentral eingesammelt und an Suche, Monitoring und Sicherheitsanalyse verteilt.
• Echtzeit-Auswertung: Betrugserkennung im Zahlungsverkehr, Lagerbestände, Preisanpassungen oder Dashboards, die Sekunden statt Stunden alt sind.

Bekannte Großanwender wie LinkedIn, Netflix oder Uber haben öffentlich über ihre Kafka-Installationen berichtet. Für die Entscheidung im eigenen Unternehmen sind solche Namen aber wenig aussagekräftig: Die wenigsten Firmen haben deren Datenmengen.

Selbst betreiben oder als Cloud-Dienst?

Ein produktiver Kafka-Cluster verlangt Know-how: Partitionen planen, Replikation konfigurieren, Speicher und Netzwerk dimensionieren, Upgrades einspielen, Verzögerungen bei Consumern überwachen. Für viele Teams sind deshalb verwaltete Dienste attraktiv, etwa Confluent Cloud, Amazon MSK oder Aiven. Azure Event Hubs bietet eine Kafka-kompatible Schnittstelle, ohne dass ein Kafka-Cluster betrieben wird. Daneben gibt es Kafka-kompatible Alternativen wie Redpanda, die mit den gleichen Client-Bibliotheken angesprochen werden.

Der Selbstbetrieb lohnt sich vor allem, wenn Daten das eigene Rechenzentrum nicht verlassen dürfen, sehr hohe Datenmengen anfallen oder ohnehin ein Plattformteam mit Kubernetes-Erfahrung existiert. Für den Einstieg und kleinere Volumina ist ein verwalteter Dienst meist günstiger, wenn man die Arbeitszeit des eigenen Teams mitrechnet.

Unabhängig vom Betriebsmodell gilt: Ereignisse sind oft personenbezogen, etwa Bestellungen oder Klickpfade. Lange Aufbewahrungszeiten müssen zu den Löschpflichten der DSGVO passen, und der Zugriff auf Topics sollte über Berechtigungen und Verschlüsselung abgesichert sein.

Was Kafka für Ihr Unternehmen bedeutet

Kafka ist kein Allheilmittel und kein Selbstzweck. Es ist ein Werkzeug für eine bestimmte Art von Problem: Viele Systeme müssen zuverlässig und zeitnah von denselben Ereignissen erfahren. Wo das zutrifft, ersetzt Kafka ein Geflecht aus Schnittstellen durch ein gemeinsames, nachvollziehbares Datenrückgrat. Dass sich die Plattform über mehr als ein Jahrzehnt in sehr unterschiedlichen Branchen gehalten hat, spricht für das Konzept.

Überschätzt wird dagegen oft, wie schnell der Nutzen eintritt. Der eigentliche Aufwand liegt selten in der Installation, sondern im Design: Welche Ereignisse gibt es, wem gehören sie, wie werden Formate versioniert (etwa mit einer Schema Registry), was passiert bei Fehlern? Unsere Empfehlung: mit einem klar abgegrenzten Anwendungsfall beginnen, etwa der Verteilung von Bestellungen oder Stammdatenänderungen, und Kafka erst dann zur zentralen Plattform ausbauen, wenn sich das Modell bewährt hat.

Wer Kafka im eigenen Haus einführen, eine bestehende Installation auf KRaft umstellen oder das Team schulen möchte, findet auf unserer Themenseite zu Apache Kafka: Beratung, Coaching und Seminare einen Überblick über Formate und Inhalte.

Häufige Fragen zu Apache Kafka

Ist Kafka nur für große Unternehmen sinnvoll?

Nein, aber der Bedarf entscheidet, nicht die Firmengröße. Auch ein mittelständisches Unternehmen kann viele Systeme haben, die dieselben Daten brauchen. Für wenige Nachrichten zwischen zwei Anwendungen ist eine einfache Warteschlange jedoch meist die pragmatischere Lösung.

Kann Kafka eine Datenbank ersetzen?

In der Regel nicht. Kafka speichert Ereignisse dauerhaft und in Reihenfolge, bietet aber keine flexiblen Abfragen über beliebige Felder. Üblich ist die Kombination: Kafka verteilt Änderungen, Datenbanken und Data Warehouses halten den abfragbaren Zustand.

Braucht Kafka noch ZooKeeper?

Für neue Installationen nicht. Seit Kafka 4.0 arbeitet Kafka ausschließlich im KRaft-Modus. Bestehende ZooKeeper-Cluster müssen vor einem Upgrade auf 4.x migriert werden.

Welche Hardware braucht Kafka?

Kafka läuft auf handelsüblichen Servern oder virtuellen Maschinen. Entscheidend sind schnelle, ausreichend große Datenträger und ein gutes Netzwerk, da Kafka Daten sequenziell schreibt und zwischen Brokern repliziert. Für Tests genügt ein Laptop.