Event Streaming mit Apache Kafka

Einordnung — Streaming statt Queueing

Apache Kafka ist eine verteilte Streaming-Plattform — kein Message-Broker im klassischen Sinn, sondern ein dauerhaft skalierbarer, partitionierter Commit-Log. Wer diesen Unterschied verstanden hat, hat den wichtigsten konzeptionellen Schritt zwischen RabbitMQ und Kafka bereits hinter sich.

Der Unterschied ist nicht akademisch. Bei einem klassischen Queue-Broker landet eine Nachricht in einer Queue, wird an einen Consumer ausgeliefert und ist anschließend weg. Bei Kafka landet ein Event in einer Partition eines Topics, bleibt dort für die konfigurierte Retention-Zeit (Stunden, Tage, Wochen, im Extremfall unbegrenzt) und kann von beliebig vielen Consumern beliebig oft gelesen werden — auch nachträglich. Aus „Nachricht zustellen und vergessen" wird „Ereignis schreiben und auf Abruf bereitstellen".

Diese Eigenschaft macht Kafka zur Standardarchitektur für drei Anwendungsbereiche, die in den letzten Jahren in praktisch jeder größeren Plattform aufgetaucht sind. Erstens: Event-Sourcing. Der Zustand einer Anwendung wird als Strom von Zustandsänderungen modelliert; der aktuelle Zustand entsteht durch das Abspielen aller Events. Zweitens: Microservice-Integration. Statt synchroner REST-Aufrufe zwischen Services kommunizieren sie asynchron über Events — entkoppelt, ausfallresistenter, einfacher zu erweitern. Drittens: Log-Aggregation und Stream-Processing. Logfiles, Metriken oder Sensordaten werden zentral gesammelt, in Echtzeit gefiltert, angereichert und in Downstream-Systeme weitergeleitet.

Kafka wurde 2010 bei LinkedIn entwickelt, 2011 als Open-Source-Projekt veröffentlicht und ist seit 2012 ein Apache-Top-Level-Projekt. Die kommerzielle Schwester ist Confluent — die Firma der ursprünglichen LinkedIn-Entwicklerinnen und -Entwickler, die zusätzliche Komponenten (Schema Registry, KSQL, Connect-Konnektoren) und eine Cloud-Variante anbietet. Lizenz: Apache 2.0 für den Kern. Reife: extrem hoch — Kafka läuft heute bei Netflix, LinkedIn, Uber, Pinterest, Spotify, der Deutschen Telekom und unzähligen weiteren Plattformen produktiv, oft mit Cluster-Größen jenseits von hundert Brokern.

Eine ehrliche Vorwarnung: Kafka ist mächtig, aber kein Werkzeug für nebenbei. Ein produktives Cluster braucht Aufmerksamkeit beim Sizing, beim Monitoring, beim Versions-Upgrade-Pfad und bei der Disaster-Recovery-Strategie. Wer „nur asynchrone Nachrichten zwischen zwei Services" möchte, fährt mit RabbitMQ einfacher. Wer Streams als zentrales Architekturprinzip versteht, hat in Kafka das Werkzeug, mit dem sich Plattformen aufbauen lassen, deren Skalierung über Jahre planbar bleibt.

Kernkonzepte — Topics, Partitionen, Offsets

Die meisten Probleme im praktischen Umgang mit Kafka lassen sich auf ein fehlendes Verständnis von drei Konzepten zurückführen: was ein Topic ist, wie es partitioniert wird und wie ein Consumer seinen Lese-Fortschritt verwaltet.

Topic — die logische Sammlung von Events

Ein Topic ist die fachliche Kategorie, in die Events geschrieben werden — typischerweise nach einem Geschäftsereignis benannt: orders, payments, user-clicks, iot-telemetry. Topics werden in Kafka explizit angelegt; im Gegensatz zu Queue-Brokern existieren sie nicht implizit, sobald jemand etwas schreibt. Das ist eine bewusste Designentscheidung: ein Topic ist ein fachliches Asset, dessen Lebenszyklus, Retention und Schema bewusst entschieden werden sollten.

Partition — die Skalierungseinheit

Jedes Topic besteht aus einer oder mehreren Partitionen. Eine Partition ist ein append-only Log: neue Events werden hinten angehängt, niemals in der Mitte eingefügt oder geändert. Innerhalb einer Partition gilt strikte Reihenfolge — Event N+1 wurde nach Event N geschrieben. Zwischen Partitionen gilt diese Reihenfolge nicht. Das ist die wichtigste Eigenschaft, die in der Praxis Stolpersteine produziert: wer Reihenfolge braucht, muss Events mit demselben Schlüssel in dieselbe Partition routen.

Die Partition ist auch die Einheit der Skalierung. Mehr Partitionen bedeuten mehr parallel arbeitende Consumer. Eine zehnstellige Anzahl von Events pro Sekunde lässt sich auf Hunderte von Partitionen verteilen, die wiederum auf Dutzende von Brokern verteilt sind. Die Faustregel: zwischen 10 und 100 Partitionen pro Topic sind in den meisten Setups angemessen. Mehrere tausend Partitionen pro Broker sind technisch möglich, aber operativ unangenehm.

Partition-Key — die Routing-Entscheidung

Wenn ein Producer ein Event schreibt, wählt er einen Key. Aus diesem Key berechnet Kafka per Hash-Funktion, in welche Partition das Event geschrieben wird. Ohne Key wird per Round-Robin verteilt. Mit Key landen alle Events mit demselben Key in derselben Partition — und behalten damit ihre Reihenfolge. In einem orders-Topic ist die customer_id ein guter Key: alle Bestellungen eines Kunden landen in derselben Partition, und ein Consumer kann sie der Reihe nach abarbeiten.

Offset — der Lese-Fortschritt

Jedes Event in einer Partition bekommt eine fortlaufende Nummer — den Offset. Offsets beginnen bei 0 und wachsen mit jedem neuen Event monoton. Ein Consumer verwaltet seinen aktuellen Lese-Stand pro Partition als „der zuletzt verarbeitete Offset". Diese Information wird in einem speziellen internen Topic (__consumer_offsets) gespeichert, sodass ein Consumer nach einem Neustart genau dort weitermacht, wo er aufgehört hat — oder, je nach Konfiguration, von Anfang an liest, was der eigentliche Replay-Mechanismus von Kafka ist.

Consumer Group — die Lastverteilung

Mehrere Consumer-Instanzen können sich zu einer Consumer Group zusammenschließen. Kafka verteilt die Partitionen eines Topics auf die Mitglieder der Group — jede Partition wird von genau einem Consumer der Group gelesen. Bei drei Partitionen und zwei Consumern liest der eine Consumer zwei Partitionen, der andere eine. Bei drei Consumern liest jeder genau eine. Bei vier Consumern bleibt einer leer. Mehrere unabhängige Consumer Groups lesen dasselbe Topic vollständig — das ist der Mechanismus, der Kafka so flexibel im Multi-Subscriber-Modell macht: ein Topic, beliebig viele Lese-Pipelines.

Cluster, Broker und das Ende von ZooKeeper

Ein Kafka-Cluster besteht aus mehreren Brokern und einem Metadaten-Mechanismus, der die Cluster-Mitglieder koordiniert. Bis vor wenigen Jahren war dieser Mechanismus ein separates ZooKeeper-Ensemble; seit Kafka 3.3 ist er als KRaft direkt in den Brokern integriert. Wer heute ein neues Cluster aufbaut, sollte KRaft wählen — ZooKeeper-Setups laufen aus und werden in Kafka 4.0 endgültig nicht mehr unterstützt.

Broker

Ein Broker ist eine einzelne Kafka-Instanz, die Partitionen hält und Producer-/Consumer-Verbindungen bedient. Ein produktives Cluster besteht in der Regel aus mindestens drei Brokern — drei ist die Mindestanforderung für eine sinnvolle Replikation, weil sich damit ein Broker-Ausfall ohne Datenverlust verkraften lässt. In großen Setups sind Cluster mit zwanzig, fünfzig oder hundert Brokern normal. Die Broker sind untereinander gleichberechtigt — keine Master-Slave-Hierarchie auf Broker-Ebene.

Controller

Innerhalb des Clusters gibt es jedoch eine Rolle, die unter den Brokern gewählt wird: den Controller. Der Controller verwaltet Metadaten — welche Partition liegt auf welchem Broker, welcher Broker ist Leader für welche Partition, welche Replikate sind aktuell in-sync. Mit ZooKeeper war diese Rolle einer der Broker; im KRaft-Modus existiert sie als eigenständiges Quorum (drei oder fünf Knoten, typischerweise auf denselben Maschinen wie die Broker oder auf dedizierten Controllern bei sehr großen Clustern).

KRaft — warum es ZooKeeper ablöst

ZooKeeper war historisch das externe Koordinations-System, ohne das Kafka nicht laufen konnte. Es war robust, aber es war auch ein zweiter Stack, der eigenständig betrieben, überwacht, upgegradet und gesichert werden musste. KRaft (Kafka Raft) ist das im Kafka-Code implementierte Raft-Konsens-Protokoll, das diese Aufgabe übernimmt. Der Vorteil ist nicht primär technisch — beide Ansätze sind robust —, sondern operativ: ein Stack statt zwei, eine Anlaufstelle für Fehlersuche, ein Versionsmanagement. Wer heute neu aufsetzt, hat keinen guten Grund mehr, ZooKeeper anzufassen.

Leader und Follower

Jede Partition hat in einem replizierten Cluster genau einen Leader und mehrere Follower. Producer und Consumer sprechen immer den Leader an. Follower kopieren die Daten asynchron vom Leader und stehen bereit, im Fehlerfall den Lead zu übernehmen. Die Anzahl der Replikate ist ein Topic-Setting (replication.factor) — drei ist der Standardwert in produktiven Setups, sodass bis zu zwei gleichzeitige Broker-Ausfälle ohne Datenverlust überstanden werden.

Architektur im Bild

Die folgende Abbildung zeigt ein typisches Drei-Broker-Cluster mit einem KRaft-Controller-Quorum, zwei Producern und zwei Consumer Groups. Das gezeigte Topic orders hat drei Partitionen (P0, P1, P2) mit Replikationsfaktor drei — jede Partition ist auf allen drei Brokern vorhanden, aber nur einer hält die Leader-Rolle.

Producer, Consumer und die Frage der Zustellgarantien

Drei Garantien, eine Wahl pro Anwendung — die wichtigste Designentscheidung beim Schreiben in Kafka liegt im Trade-off zwischen Latenz, Durchsatz und Zustellsicherheit.

At-most-once, at-least-once, exactly-once

Klassisch gibt es drei Zustellgarantien. At-most-once bedeutet: jede Nachricht wird höchstens einmal verarbeitet, kann aber bei Fehlern verloren gehen. At-least-once bedeutet: jede Nachricht wird mindestens einmal verarbeitet, kann bei Wiederholungen aber doppelt ankommen. Exactly-once bedeutet: jede Nachricht wird genau einmal verarbeitet — der Heilige Gral, der lange als nicht realisierbar galt und seit Kafka 0.11 in einem klar definierten Rahmen unterstützt wird.

Producer-Konfiguration

Auf der Producer-Seite sind drei Parameter entscheidend:

• acks — wie viele Replikate eine geschriebene Nachricht bestätigt haben müssen, bevor der Producer den Send als erfolgreich betrachtet. acks=0 ist Fire-and-Forget (höchste Performance, keine Zustellgarantie). acks=1 wartet auf den Leader (Standard, aber bei Leader-Ausfall verlustbehaftet). acks=all wartet auf alle In-Sync-Replicas — die einzige Einstellung, die Datenverlust bei Broker-Ausfällen verlässlich ausschließt.
• retries und retry.backoff.ms — wie oft und in welchem Abstand der Producer einen fehlgeschlagenen Send wiederholt. In Verbindung mit acks=all entsteht so at-least-once-Semantik.
• enable.idempotence=true — Kafka vergibt jeder Producer-Session eine ID und nummeriert die Nachrichten. Doppelt zugestellte Nachrichten erkennt der Broker an Sequenznummer und ID und verwirft sie. Aus at-least-once wird damit effektives exactly-once auf Producer-Seite. Das sollte heute der Default für jede neue Anwendung sein.

Consumer-Konfiguration

Auf der Consumer-Seite ist die zentrale Frage, wann der Lese-Fortschritt (Offset) committed wird. Standardmäßig macht der Consumer das im Hintergrund alle paar Sekunden — bequem, aber bei einem Crash zwischen Verarbeitung und Commit gehen Nachrichten verloren oder werden doppelt verarbeitet. Die robustere Variante ist manuelles Committen nach erfolgreicher Verarbeitung:

props = {
    "bootstrap.servers": "kafka-1:9092,kafka-2:9092,kafka-3:9092",
    "group.id":           "billing",
    "enable.auto.commit": False,
    "auto.offset.reset":  "earliest",
}

consumer = KafkaConsumer("orders", **props)
for message in consumer:
    process_order(message.value)   # idempotente Verarbeitung!
    consumer.commit()              # erst nach Erfolg den Offset speichern

Wichtig dabei: die Verarbeitung selbst muss idempotent sein, sonst bringt exactly-once auf Producer-Seite und manuelles Committen auf Consumer-Seite zusammen immer noch Doppelverarbeitung beim Crash zwischen Schreiben des Ergebnisses und Committen des Offsets. In der Praxis erreicht man Idempotenz über eine eindeutige Event-ID, die im Downstream-System (z. B. Datenbank) als Unique-Constraint geprüft wird.

Transactional API

Für Anwendungen, die innerhalb einer einzelnen Transaktion sowohl aus einem Topic lesen als auch in ein anderes schreiben (klassisches Read-Process-Write-Muster), bietet Kafka eine Transactional API. Damit lassen sich Schreiben in mehrere Topics plus das Committen des Quell-Offsets in einer atomaren Operation bündeln. Das ist die saubere End-to-End-Exactly-once-Lösung — gleichzeitig die mit Abstand komplexeste Konfiguration und im Tagesgeschäft nur ein Bruchteil der Setups, in denen sie tatsächlich erforderlich ist.

Replikation und Hochverfügbarkeit

Replikation ist nicht nur ein nettes Feature, sondern das Fundament jeder produktiven Kafka-Installation. Ohne Replikation ist jeder Broker-Ausfall potenziell ein Datenverlust.

Jede Partition wird N-fach repliziert, wobei N der replication.factor des Topics ist. Standardwert in produktiven Setups: drei. Damit verteilt sich jede Partition über drei verschiedene Broker. Einer hält die Leader-Rolle, die anderen zwei sind Follower und kopieren die Daten kontinuierlich vom Leader. Producer und Consumer sprechen ausschließlich den Leader an.

Der Begriff ISR (In-Sync Replicas) ist zentral. Die ISR-Liste einer Partition enthält alle Replikate, die mit dem Leader synchron sind — das heißt, sie haben in den letzten replica.lag.time.max.ms Millisekunden (Standard: 30 Sekunden) alle Nachrichten vom Leader gezogen. Fällt ein Follower zurück, fliegt er aus der ISR. Ein Broker-Ausfall führt dazu, dass alle Partitionen, deren Leader auf diesem Broker liegen, neu gewählt werden — der Controller wählt aus der ISR einen neuen Leader. Sind keine ISR-Mitglieder mehr da (z. B. nach mehreren gleichzeitigen Ausfällen), wird die Partition unverfügbar — es sei denn, man hat unclean.leader.election=true gesetzt, was Verfügbarkeit gegen mögliche Datenverluste tauscht. Dieser Schalter steht standardmäßig auf false und sollte dort auch bleiben.

Die Min-ISR-Einstellung bestimmt, wie viele Replikate mindestens in der ISR sein müssen, damit ein Producer mit acks=all überhaupt erfolgreich schreiben darf. Bei replication.factor=3 und min.insync.replicas=2 ist sichergestellt: selbst wenn ein Broker ausfällt, läuft das Topic weiter; fallen zwei aus, sind Producer in einem Schreibstopp, aber kein Datenverlust. Diese Kombination ist der Industriestandard für produktive Kafka-Cluster.

Über die einfache Replikation hinaus existiert mit MirrorMaker 2 (auf Connect aufgebaut) ein Mechanismus für Cluster-übergreifende Replikation — typischerweise zwischen Rechenzentren oder zwischen einer On-Premise- und einer Cloud-Region. Für Disaster-Recovery-Setups ist MirrorMaker 2 das richtige Werkzeug; in jeder Multi-Region-Architektur sollte er von Anfang an mit eingeplant werden.

Setup mit Docker Compose

Für ein lokales Setup oder eine Entwicklungsumgebung reicht ein Single-Broker-Cluster im KRaft-Modus, das in einer einzelnen Compose-Datei lebt. Für Produktion sind drei Broker plus ein dedizierter Controller-Quorum nötig — die hier gezeigte Konfiguration lässt sich aber direkt als Vorlage skalieren.

Schritt 1 — eine docker-compose.yml-Datei anlegen:

services:
  kafka:
    image: confluentinc/cp-kafka:7.6.0
    container_name: kafka
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: 'broker,controller'
      KAFKA_LISTENERS: 'PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093'
      KAFKA_ADVERTISED_LISTENERS: 'PLAINTEXT://localhost:9092'
      KAFKA_CONTROLLER_LISTENER_NAMES: 'CONTROLLER'
      KAFKA_INTER_BROKER_LISTENER_NAME: 'PLAINTEXT'
      KAFKA_CONTROLLER_QUORUM_VOTERS: '1@kafka:9093'
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: |
        CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_LOG_DIRS: '/var/lib/kafka/data'
      CLUSTER_ID: 'MkU3OEVBNTcwNTJENDM2Qk'
    volumes:
      - kafka-data:/var/lib/kafka/data

volumes:
  kafka-data:

Schritt 2 — Cluster starten und ein Topic anlegen:

docker compose up -d

docker exec -it kafka \
  kafka-topics --bootstrap-server localhost:9092 \
               --create --topic orders \
               --partitions 3 --replication-factor 1

Schritt 3 — Producer und Consumer von der Kommandozeile testen:

# In einer Shell — interaktiver Producer:
docker exec -it kafka \
  kafka-console-producer --bootstrap-server localhost:9092 \
                         --topic orders

# In einer zweiten Shell — Consumer ab Anfang des Topics:
docker exec -it kafka \
  kafka-console-consumer --bootstrap-server localhost:9092 \
                         --topic orders --from-beginning

Schritt 4 — ein minimaler Python-Producer, der reale Events schreibt:

from kafka import KafkaProducer
import json

producer = KafkaProducer(
    bootstrap_servers     = "localhost:9092",
    value_serializer      = lambda v: json.dumps(v).encode("utf-8"),
    key_serializer        = lambda k: str(k).encode("utf-8"),
    acks                  = "all",
    enable_idempotence    = True,
)

producer.send(
    "orders",
    key   = "customer-42",
    value = {"order_id": 1001, "customer_id": 42, "total": 99.95}
)
producer.flush()

Schritt 5 — der passende Consumer, mit manuellem Committen:

from kafka import KafkaConsumer
import json

consumer = KafkaConsumer(
    "orders",
    bootstrap_servers   = "localhost:9092",
    group_id            = "billing",
    enable_auto_commit  = False,
    auto_offset_reset   = "earliest",
    value_deserializer  = lambda m: json.loads(m.decode("utf-8")),
)

for message in consumer:
    print(f"Partition {message.partition} Offset {message.offset}:")
    print(f"  Key={message.key} Value={message.value}")
    # ... Verarbeitung (muss idempotent sein) ...
    consumer.commit()

Streams, Connect, Schema Registry

Der Kern-Broker ist nur die Hälfte der Geschichte. Drei Begleitkomponenten machen aus Kafka eine vollständige Streaming-Plattform.

Kafka Streams — Verarbeitung im Anwendungs-Prozess

Kafka Streams ist eine Java-Bibliothek, die Stream-Processing direkt in der eigenen Anwendung verfügbar macht — ohne dass ein separater Cluster wie Spark oder Flink betrieben werden müsste. Die Bibliothek bietet die typischen Operationen: map, filter, groupBy, aggregate, join, mit zeitlichen Fenstern. Interner Zustand (z. B. Zähler, Aggregate) wird in einer eingebetteten RocksDB-Instanz pro Anwendungs-Instanz gehalten und über eigene Topics in Kafka selbst gesichert. Damit skaliert Streams horizontal: mehrere Anwendungs-Instanzen teilen sich die Partitionen, ohne dass ein zentraler Koordinator nötig ist.

Wer mit Streams arbeitet, sollte den Begriff KTable kennen: eine Sicht auf ein Topic als „aktuellster Wert pro Schlüssel". KTables sind das Mittel, um aus Event-Strömen einen abfragbaren Zustand zu bauen — das fachliche Pendant zu einer materialized view in einer Datenbank.

Kafka Connect — Integration mit der Außenwelt

Connect ist ein Framework für vorgefertigte Konnektoren — Source-Konnektoren ziehen Daten aus externen Systemen in Kafka, Sink-Konnektoren schreiben Kafka-Daten in externe Systeme. Es gibt Hunderte fertiger Konnektoren: Postgres, MySQL, MongoDB, S3, Elasticsearch, Snowflake, Salesforce, Datadog, Splunk. Ein Debezium-Konnektor (das Standard-Werkzeug für Change-Data-Capture) liest die WAL-Logs einer Postgres-Datenbank und schiebt jede Zeile als Event in Kafka — die Standard-Methode, um relationale Daten in Echtzeit in einen Event-Stream zu überführen.

Schema Registry — Verträge zwischen Producern und Consumern

Eine der unangenehmsten Eigenschaften eines unkontrollierten Kafka-Setups: ein Producer ändert das JSON-Format, alle Consumer brechen schweigend. Die Schema Registry (ein separater Dienst, kein Teil des Kerns) löst das, indem sie Schemas — typischerweise Apache Avro, alternativ JSON Schema oder Protocol Buffers — zentral hält. Producer und Consumer prüfen vor dem Schreiben/Lesen das Schema gegen die Registry. Schema-Änderungen unterliegen einer Kompatibilitätsregel (backward, forward, full), die rückwirkende Brüche verhindert. Wer Kafka über mehrere Teams hinweg produktiv einsetzt, sollte die Schema Registry vom ersten Tag an einplanen — ohne sie verkommt das Datenmodell schnell zur Black Box.

KSQL / ksqlDB

Eine SQL-ähnliche Sprache, mit der sich Streams und KTables abfragen und transformieren lassen, ohne eine Zeile Java-Code zu schreiben. ksqlDB läuft als eigener Server-Prozess und ist für Teams attraktiv, die SQL als Lingua Franca haben und schnelle Stream-Aggregationen ohne Code-Stack aufsetzen wollen.

Unterschied zu RabbitMQ — zwei verwandte, aber sehr unterschiedliche Werkzeuge

Kafka und RabbitMQ landen in Vergleichsgesprächen oft nebeneinander, weil beide „Nachrichten" zwischen Systemen transportieren. Auf dieser Ebene endet die Ähnlichkeit. Die Werkzeuge stehen für zwei unterschiedliche Sichten auf asynchrone Kommunikation.

Das fundamentale Konzept

RabbitMQ ist ein klassischer Message-Broker im AMQP-0-9-1-Geiste. Nachrichten kommen in einen Exchange, werden anhand von Bindings und Routing-Keys in Queues verteilt, dort von Consumern abgeholt und verschwinden. Eine Nachricht hat eine bestimmte Lebensdauer: vom Schreiben bis zum Ack. Wer „die Nachricht von gestern" haben will, hat Pech — sie ist weg, weil sie konsumiert wurde.

Kafka ist ein verteilter Commit-Log. Events werden geschrieben, bleiben gespeichert (Tage, Wochen, Monate), und Consumer entscheiden, ab welchem Offset sie lesen wollen. „Die Nachricht von gestern" ist trivial — der Offset wird auf gestern gesetzt und der gesamte Strom wird neu verarbeitet.

Die typischen Stolpersteine im Vergleich

Routing-Flexibilität. RabbitMQ ist hier deutlich expressiver. Ein topic-Exchange mit Routing-Patterns wie orders.*.cancelled oder ein headers-Exchange mit attribut-basierten Bindings erlauben Verteilungsmuster, die in Kafka nur über das Topic-Naming oder zusätzliche Stream-Processing-Schritte abbildbar sind. Wer fachlich komplexes Routing braucht und keinen Streaming-Aspekt hat, fährt mit RabbitMQ einfacher.

Per-Message-TTL und Priority-Queues. RabbitMQ unterstützt Time-to-Live pro Nachricht und Priority-Queues nativ. Kafka kennt diese Konzepte nicht — alle Events einer Partition haben dieselbe Retention, und Reihenfolge ist Reihenfolge (kein Vorziehen wichtiger Nachrichten). Anwendungen wie „dringende Bestellungen zuerst" sind in RabbitMQ trivial, in Kafka eine Architektur-Übung.

Push versus Pull. RabbitMQ pusht Nachrichten an den Consumer, sobald sie da sind. Kafka muss vom Consumer aktiv gepollt werden. In sehr latenzkritischen Szenarien (Sub-Millisekunde) gewinnt der Push, in jedem Szenario mit Backpressure (langsame Consumer, Lastspitzen) gewinnt der Pull, weil der Consumer das Tempo selbst bestimmt.

Replay. Die für Kafka selbstverständliche Operation „lies den Topic ab Stand vor zwei Tagen" ist in RabbitMQ schlicht nicht vorgesehen. Das Streams-Feature in RabbitMQ 3.9+ versucht, dieses Gap zu schließen, ist aber noch nicht im selben Reifegrad wie Kafka.

Durchsatz. Kafka schlägt RabbitMQ in Durchsatz-Benchmarks regelmäßig um eine Größenordnung. In den meisten Anwendungen ist das egal — wer 5.000 Nachrichten pro Sekunde verarbeitet, ist mit beiden Werkzeugen weit unterhalb der Kapazitätsgrenze. Wenn aber von 100.000 Nachrichten pro Sekunde und mehr die Rede ist, ist Kafka praktisch ohne Alternative.

Wann Kafka passt — und wann RabbitMQ die bessere Wahl ist

Beide Werkzeuge sind reif, weit verbreitet und produktionstauglich. Die richtige Wahl ergibt sich aus dem Anwendungsfall, nicht aus dem Hype.

Kafka ist die richtige Wahl, wenn …

• Events dauerhaft gespeichert und mehrfach konsumiert werden sollen — etwa für Event-Sourcing, Replay-fähige Verarbeitung oder Audit-Trails;
• der Durchsatz mehrere zehntausend Nachrichten pro Sekunde überschreitet oder absehbar überschreiten wird;
• mehrere unabhängige Consumer-Pipelines auf demselben Event-Strom arbeiten — der eine berechnet Rechnungen, der andere füttert ein Analytics-Dashboard, der dritte schickt Push-Benachrichtigungen;
• Stream-Processing Teil der Anforderung ist — Aggregate, Joins, Zeitfenster über Live-Daten;
• Change-Data-Capture aus relationalen Datenbanken etabliert werden soll — Debezium auf Kafka Connect ist hier der Standard;
• eine plattformweite Event-Architektur mit klar definierten Schemas (Schema Registry) über mehrere Teams hinweg etabliert werden soll.

RabbitMQ ist die richtige Wahl, wenn …

• klassische Task-Queues und Worker-Pools abgebildet werden — Bilder verarbeiten, Mails versenden, lange Reports berechnen;
• das Routing fachlich komplex ist und sich gut über Exchange-Typen, Routing-Keys und Header abbilden lässt;
• RPC-ähnliche Request-Reply-Muster gebraucht werden (Reply-Queue mit Correlation-ID — in RabbitMQ idiomatisch, in Kafka mühsam);
• Priority-Queues, Per-Message-TTL oder Dead-Letter-Queues mit fein einstellbarer Politik gebraucht werden;
• das System polyglott angebunden wird und neben AMQP auch MQTT (IoT) oder STOMP (Web) per Plugin bereitgestellt werden soll;
• der Betriebs-Overhead minimal sein soll und das absehbare Volumen die Möglichkeiten von RabbitMQ nicht annähernd ausschöpft.

In den meisten Plattformen, mit denen wir arbeiten, kommen beide Werkzeuge zum Einsatz — nicht gegeneinander, sondern komplementär. Ein typisches Bild: Kafka als zentrales Event-Backbone für die fachlichen Ereignisse einer Plattform (Bestellungen, Zahlungen, Statusänderungen), RabbitMQ als Task-Queue für die operative Hintergrundarbeit (Mailversand, Report-Generierung, asynchrone API-Aufrufe). Die beiden Welten überlappen sich an den Rändern, aber sie konkurrieren selten direkt. Wer beide kennt und ihre Stärken sauber trennt, baut Architekturen, die schneller liefern, leichter skalieren und sich operativ ehrlich verteidigen lassen. Eine eigene Einführung zu RabbitMQ haben wir in einem separaten Artikel beigelegt.