Apache Kafka: Messaging- und Streaming-Plattform für hoch­ska­lier­ba­re Systeme

Apache Kafka ist eine quell­of­fe­ne Plattform für Event Streaming, Messaging und Stream Pro­ces­sing. Sie speichert Er­eig­nis­se als ver­teil­tes Log, stellt diese für An­wen­dun­gen schnell und zu­ver­läs­sig bereit und bildet damit das Rückgrat moderner Event-Driven Ar­chi­tec­tures, Mi­cro­ser­vices, Change-Data-Capture-Pipelines und Echtzeit-Da­ten­platt­for­men.

Was ist Apache Kafka?

Die Software Apache Kafka ist eine platt­form­un­ab­hän­gi­ge Open-Source-Anwendung der Apache Software Foun­da­ti­on, deren Fokus auf der Spei­che­rung, Über­tra­gung und Ver­ar­bei­tung von Da­ten­strö­men liegt. Das Projekt wurde ur­sprüng­lich von LinkedIn ent­wi­ckelt und 2011 als Open-Source-Projekt ver­öf­fent­licht. Ziel war es zunächst, sehr große Mengen an Ak­ti­vi­täts-, Log- und Me­trik­da­ten zu­ver­läs­sig zwischen Systemen zu über­tra­gen.

Seitdem hat sich Apache Kafka von einem ver­teil­ten Publish-Subscribe-System zu einer um­fas­sen­den Event-Streaming-Plattform für moderne Da­ten­ar­chi­tek­tu­ren wie Data Mesh ent­wi­ckelt und bildet heute die Grundlage für Event-Driven Ar­chi­tec­tures und da­ten­ge­trie­be­ne An­wen­dun­gen in Echtzeit. Un­ter­neh­men nutzen Kafka heute, um Er­eig­nis­se aus An­wen­dun­gen, Da­ten­ban­ken, Log­sys­te­men, IoT-Geräten oder Ana­ly­se­platt­for­men in Echtzeit zu erfassen, dauerhaft vor­zu­hal­ten und an ver­schie­de­ne Ziel­sys­te­me wei­ter­zu­lei­ten.

2014 gründeten mehrere ur­sprüng­li­che Kafka-Ent­wick­ler aus dem LinkedIn-Umfeld das Un­ter­neh­men Confluent. Confluent bietet mit der Confluent Platform und Confluent Cloud kom­mer­zi­el­le Er­wei­te­run­gen und ver­wal­te­te Angebote rund um Apache Kafka an. Seit der Übernahme durch IBM im Jahr 2026 gehört Confluent als ei­gen­stän­di­ge Marke zum IBM-Portfolio. Der Kern von Apache Kafka bleibt jedoch ein Open-Source-Projekt unter der Apache-2.0-Lizenz.

Welche Grund­funk­tio­nen bietet Apache Kafka?

Apache Kafka ist darauf ausgelegt, große Mengen an Da­ten­strö­men zu­ver­läs­sig zwischen An­wen­dun­gen und Systemen zu über­tra­gen. Die Plattform ent­kop­pelt dabei Da­ten­quel­len und Ziel­sys­te­me. Producer schreiben Er­eig­nis­se in Kafka, Consumer lesen sie un­ab­hän­gig davon aus. Dadurch müssen sendende und emp­fan­gen­de Systeme nicht gleich­zei­tig verfügbar sein.

Kafka zeichnet sich durch folgende Leis­tun­gen aus:

• Zwi­schen­spei­che­rung: Er­eig­nis­se bleiben in Topics ge­spei­chert, auch wenn ein Consumer vor­über­ge­hend nicht er­reich­bar ist.
• Las­tent­kopp­lung: Producer können Daten kon­ti­nu­ier­lich schreiben, während Consumer sie in ihrem eigenen Tempo ver­ar­bei­ten.
• Ska­lie­rung: Topics werden in Par­ti­tio­nen auf­ge­teilt und über mehrere Broker verteilt. Dadurch lässt sich die Ver­ar­bei­tung par­al­le­li­sie­ren.
• Feh­ler­to­le­ranz: Par­ti­tio­nen können re­pli­ziert werden. Fällt ein Broker aus, können andere Broker die Daten weiter be­reit­stel­len.
• Wie­der­hol­bar­keit: Consumer speichern ihren Le­se­fort­schritt in Form von Offsets. Dadurch können sie nach Fehlern an de­fi­nier­ter Stelle fort­set­zen oder Daten erneut lesen.
• Trans­ak­tio­nen: Kafka un­ter­stützt idem­po­ten­te Producer-Ope­ra­tio­nen und trans­ak­tio­na­les Schreiben. Dadurch lassen sich unter be­stimm­ten Be­din­gun­gen innerhalb des Kafka-Öko­sys­tems Exactly-once-Semantik für Lese-, Ver­ar­bei­tungs- und Schreib­vor­gän­ge umsetzen.

Im Gegensatz zu einfachen Nach­rich­ten­war­te­schlan­gen ist Kafka nicht nur auf kurz­fris­ti­ge Zu­stel­lung aus­ge­rich­tet. Die Plattform speichert Er­eig­nis­se als ge­ord­ne­tes Log und macht sie für mehrere An­wen­dun­gen verfügbar. Damit eignet sie sich für Systeme, die hohe Ver­füg­bar­keit, Echt­zeit­ver­ar­bei­tung und lang­fris­tig nutzbare Da­ten­strö­me benötigen.

Die Apache-Kafka-Ar­chi­tek­tur im Überblick

Die Apache-Kafka-Ar­chi­tek­tur ist auf verteilte Ver­ar­bei­tung ausgelegt. Kafka speichert Er­eig­nis­se nicht in einer einzelnen zentralen War­te­schlan­ge, sondern verteilt sie über ein Cluster. Im Kern besteht die Ar­chi­tek­tur aus drei Ebenen:

1. Producer schreiben Er­eig­nis­se in Kafka.
2. Kafka or­ga­ni­siert diese Er­eig­nis­se in Topics (logische Container) und Par­ti­tio­nen (physische Ska­lie­rungs­ein­hei­ten).
3. Consumer lesen die Da­ten­strö­me un­ab­hän­gig von­ein­an­der aus.

Zu­sätz­lich verwaltet Kafka die Cluster-Metadaten, also In­for­ma­tio­nen über Topics, Par­ti­tio­nen und Zu­stän­dig­kei­ten im Cluster. Diese Me­ta­da­ten­ver­wal­tung erfolgte früher über Apache ZooKeeper, wird in aktuellen Kafka-Versionen aber durch Kafka KRaft direkt in Kafka selbst über­nom­men.

Broker, Topics und Par­ti­tio­nen

Ein Kafka-Cluster besteht aus mehreren Ser­ver­pro­zes­sen, die als Broker be­zeich­net werden. Broker nehmen Er­eig­nis­se entgegen, speichern sie und stellen sie für lesende An­wen­dun­gen bereit. Damit Kafka hohe Da­ten­men­gen ver­ar­bei­ten kann, werden ein­ge­hen­de Daten in Topics or­ga­ni­siert. Ein Topic ist ein logischer Da­ten­strom, etwa orders, payments, user-events oder server-logs.

Damit ein Topic ska­lier­bar bleibt, wird es in Par­ti­tio­nen un­ter­teilt. Jede Partition ist ein ge­ord­ne­tes, un­ver­än­der­li­ches Log, an dessen Ende neue Er­eig­nis­se angefügt werden. Par­ti­tio­nen können über mehrere Broker verteilt und re­pli­ziert werden. So kann Kafka viele Schreib- und Le­se­zu­grif­fe parallel ver­ar­bei­ten und gleich­zei­tig Aus­fall­si­cher­heit bieten.

Producer und Consumer

An­wen­dun­gen, die Daten in Kafka schreiben, heißen Producer. Sie senden Er­eig­nis­se an Topics und bestimmen unter anderem Schlüssel, Se­ria­li­sie­rung und weitere Metadaten. Kafka ordnet die Er­eig­nis­se an­schlie­ßend den passenden Par­ti­tio­nen zu.

An­wen­dun­gen, die Daten aus Kafka lesen, heißen Consumer. Sie lesen Er­eig­nis­se aus Topics und speichern ihren Fort­schritt über so­ge­nann­te Offsets. Mehrere Consumer können in einer Consumer Group zu­sam­men­ar­bei­ten. Kafka verteilt die Par­ti­tio­nen eines Topics dann auf die Consumer dieser Gruppe. So lässt sich die Ver­ar­bei­tung par­al­le­li­sie­ren, ohne dass jedes Ereignis innerhalb derselben Gruppe mehrfach ver­ar­bei­tet wird.

Ein zentraler Vorteil von Kafka besteht darin, dass ver­schie­de­ne Consumer-Gruppen denselben Da­ten­strom un­ab­hän­gig lesen können. Eine Anwendung kann zum Beispiel Be­stel­lun­gen ver­ar­bei­ten und eine andere Be­trugs­prü­fung ausführen. Beide nutzen denselben Event Stream, ohne von­ein­an­der abhängig zu sein.

Der Pa­ra­dig­men­wech­sel: von ZooKeeper zu KRaft

His­to­risch war Apache Kafka auf Apache ZooKeeper an­ge­wie­sen. ZooKeeper ver­wal­te­te wichtige Cluster-Metadaten, etwa In­for­ma­tio­nen zu Brokern, Topics, Par­ti­tio­nen und Leader-Wahlen. Dieses Modell war über viele Jahre stabil, brachte aber zu­sätz­li­chen Be­triebs­auf­wand mit sich: Kafka und ZooKeeper mussten separat in­stal­liert, überwacht, skaliert und ak­tua­li­siert werden.

Mit Kafka KRaft hat sich die Ar­chi­tek­tur grund­le­gend verändert. KRaft steht für „Kafka Raft“ und ersetzt ZooKeeper durch ein in Kafka in­te­grier­tes Kon­sens­pro­to­koll. Seit Kafka 4.0 läuft Kafka aus­schließ­lich im KRaft-Modus. Cluster, die noch im ZooKeeper-Modus laufen, müssen vor einem Upgrade auf eine aktuelle Kafka-Version über eine geeignete Zwi­schen­ver­si­on in den KRaft-Modus migriert werden.

Im KRaft-Modus verwaltet Kafka seine Metadaten selbst. Dafür nutzt Kafka ein Con­trol­ler-Quorum, das In­for­ma­tio­nen zu Topics, Par­ti­tio­nen, ACLs, Brokern und weiteren Clus­ter­be­stand­tei­len in einem internen Metadaten-Log speichert. Dieses Log wird innerhalb von Kafka als internes, re­pli­zier­tes Log ge­spei­chert. Dadurch wird Kafka autarker, einfacher zu betreiben und besser ska­lier­bar. Für die Praxis bedeutet das:

• Der Betrieb wird einfacher, weil kein separates ZooKeeper-Ensemble mehr nötig ist.
• Me­ta­da­ten­ope­ra­tio­nen lassen sich ef­fi­zi­en­ter durch­füh­ren.
• Con­trol­ler-Failover und Cluster-Än­de­run­gen können schneller ablaufen.
• Die Kafka-Ar­chi­tek­tur wird ver­ständ­li­cher, weil Daten und Metadaten im Kafka-Ökosystem selbst verwaltet werden.

Tech­ni­sche Grund­la­gen: Die Kafka-Schnitt­stel­len

Um An­wen­dun­gen den Zugriff auf Apache Kafka zu gewähren, stellt die Software ver­schie­de­ne APIs bereit. Die fünf wich­tigs­ten Schnitt­stel­len sind die folgenden:

• Kafka Producer: Die Producer-API er­mög­licht An­wen­dun­gen, Er­eig­nis­se an Kafka-Topics zu senden. Producer bestimmen unter anderem Topic, Key, Wert, Par­ti­tio­nie­rungs­lo­gik und Zu­stell­kon­fi­gu­ra­ti­on.
• Kafka Consumer: Über die Consumer API lesen An­wen­dun­gen Er­eig­nis­se aus Topics. Consumer können einzeln oder in Consumer Groups arbeiten und ihren Le­se­fort­schritt über Offsets steuern.
• Kafka Streams: Die Streams API ist eine Java-Bi­blio­thek für Stream Pro­ces­sing. An­wen­dun­gen können Daten aus Kafka lesen, trans­for­mie­ren, agg­re­gie­ren, an­rei­chern und wieder in Kafka schreiben.
• Kafka Connect: Kafka Connect dient der In­te­gra­ti­on externer Systeme. Über wie­der­ver­wend­ba­re Source- und Sink-Con­nec­to­ren lassen sich Da­ten­ban­ken, Da­tei­sys­te­me, Such­ma­schi­nen, Data Warehou­ses oder Cloud-Dienste mit Kafka verbinden.
• Kafka Ad­min­Cli­ent: Der Ad­min­Cli­ent dient der Ver­wal­tung und Über­wa­chung eines Kafka-Clusters. Damit lassen sich zum Beispiel Topics erstellen, Kon­fi­gu­ra­tio­nen ändern, ACLs verwalten oder Cluster-Metadaten abfragen.

Die Kom­mu­ni­ka­ti­on zwischen Cli­ent­an­wen­dun­gen und einzelnen Servern des Apache-Clusters erfolgt über ein simples, leis­tungs­star­kes und spra­chen­un­ab­hän­gi­ges Protokoll auf Grundlage von TCP. Neben dem of­fi­zi­el­len Java-Client exis­tie­ren Clients für zahl­rei­che andere Pro­gram­mier­spra­chen, darunter Python, Go, C/C++, PHP, Ruby und .NET.

Ein­satz­sze­na­ri­en für Apache Kafka

Apache Kafka ist von Beginn an für einen hohen Schreib- und Le­se­durch­satz kon­zi­piert worden. In Kom­bi­na­ti­on mit den auf­ge­zähl­ten APIs sowie der hohen Ska­lier­bar­keit, Re­pli­ka­ti­on und dem wie­der­hol­ba­ren Lesen eignet sich die Plattform für ver­schie­de­ne tech­ni­sche und ge­schäft­li­che An­wen­dungs­fäl­le. Typische Ein­satz­sze­na­ri­en sind:

• Event-Driven Ar­chi­tec­tu­re mit Kafka: In einer Event-Driven Ar­chi­tec­tu­re (EDA) kom­mu­ni­zie­ren Mi­cro­ser­vices asynchron über Er­eig­nis­se. Statt sich ge­gen­sei­tig synchron per REST oder RPC auf­zu­ru­fen, ver­öf­fent­li­chen Services Events wie OrderCreated, PaymentConfirmed oder UserRegistered. Andere Services reagieren darauf, ohne den Producer zu blo­ckie­ren. Das reduziert Kopplung, ver­hin­dert Kas­ka­den­feh­ler und er­leich­tert un­ab­hän­gi­ge Ska­lie­rung.
• Messaging und Sys­tem­in­te­gra­ti­on: Kafka kann als Messaging-Schicht zwischen An­wen­dun­gen dienen. Dabei eignet sich die Plattform besonders, wenn Nach­rich­ten nicht nur kurz­fris­tig zu­ge­stellt, sondern auch ge­spei­chert, verteilt und später erneut gelesen werden sollen.
• Web-Analytics & User-Tracking: Kafka wird häufig zur Erfassung und Aus­wer­tung von Nut­zer­inter­ak­tio­nen ein­ge­setzt. Er­eig­nis­se wie Page Views, Klicks oder Käufe werden in Echtzeit gesammelt und können sowohl für Mo­ni­to­ring als auch für ana­ly­ti­sche Aus­wer­tun­gen genutzt werden.
• Change Data Capture mit Kafka: Da­ten­bank­än­de­run­gen können über Debezium und Kafka Connect in Echtzeit in Kafka gestreamt werden. Das ist nützlich für Da­ten­re­pli­ka­ti­on, Outbox-Pattern, Syn­chro­ni­sie­rung von Such­in­di­zes, ana­ly­ti­sche Pipelines und Mi­cro­ser­vice-In­te­gra­ti­on.
• Stream Pro­ces­sing: Mit Kafka Streams, Apache Flink oder ksqlDB lassen sich Da­ten­strö­me während des Trans­ports ver­ar­bei­ten und Muster erkennen. Beispiele sind Ag­gre­ga­tio­nen, An­rei­che­rung mit Stamm­da­ten, Echtzeit-Be­trugs­er­ken­nung, Ses­sio­ni­sie­rung oder Echtzeit-Mo­ni­to­ring.
• IoT-Da­ten­ver­ar­bei­tung: Kafka eignet sich für die Ver­ar­bei­tung großer Mengen kon­ti­nu­ier­li­cher Sen­sor­da­ten, etwa aus In­dus­trie­an­la­gen, Fahr­zeu­gen oder Smart-Devices, und er­mög­licht deren Wei­ter­lei­tung an Analyse- und Mo­ni­to­ring-Systeme.
• Event Sourcing: An­wen­dun­gen können Er­eig­nis­se als zentrale Quelle des Sys­tem­zu­stands speichern. Der aktuelle Zustand wird aus der Er­eig­nis­his­to­rie ab­ge­lei­tet. Kafka eignet sich dafür vor allem bei hohen Da­ten­men­gen und mehreren un­ab­hän­gi­gen Consumern.
• Log- und Me­trik­ver­ar­bei­tung: Kafka kann Logdaten, Metriken und Traces aus ver­teil­ten Systemen sammeln und an Mo­ni­to­ring-, Ob­ser­va­bi­li­ty- oder Ana­ly­se­platt­for­men wei­ter­lei­ten.
• Data Mesh und Echtzeit-Da­ten­platt­for­men: In Data-Mesh-Ar­chi­tek­tu­ren können Fach­do­mä­nen eigene Da­ten­pro­duk­te be­reit­stel­len. Kafka dient dabei als Echtzeit-Rückgrat, über das Daten zwischen Domänen, Platt­for­men und Ana­ly­se­werk­zeu­gen verteilt werden.

In realen Ar­chi­tek­tu­ren treten diese Szenarien selten isoliert auf. Häufig wird Kafka gleich­zei­tig für Messaging, Event Streaming und Da­ten­in­te­gra­ti­on ein­ge­setzt und bildet damit das Rückgrat moderner, event­ge­trie­be­ner Systeme.

Wie wird Apache Kafka heute betrieben?

Apache Kafka kann auf un­ter­schied­li­che Weise betrieben werden. Die passende Variante hängt von Kontrolle, Budget, Com­pli­ance-An­for­de­run­gen, internem Know-how und Ska­lie­rungs­be­darf ab.

Self-Managed auf Bare Metal oder Cloud-Servern

Im Falle der Selbst­ver­wal­tung übernimmt das eigene Team die Ein­rich­tung des Kafka-Clusters sowie die Kon­fi­gu­ra­ti­on und den laufenden Betrieb der Plattform. Das kann auf Bare-Metal-Servern, vir­tu­el­len Maschinen oder leis­tungs­star­ken Cloud-Servern erfolgen. Diese Variante bietet maximale Kontrolle über Be­triebs­sys­tem, Netzwerk, Storage, Broker-Kon­fi­gu­ra­ti­on, Security, Upgrade-Zyklen und Mo­ni­to­ring.

Self-Managed Kafka eignet sich vor allem für Or­ga­ni­sa­tio­nen mit er­fah­re­nen Platform- oder Data-En­gi­nee­ring-Teams, strengen Com­pli­ance-Vorgaben oder sehr spe­zi­fi­schen An­for­de­run­gen an Netzwerk, Da­ten­re­si­denz und Per­for­mance. Der Nachteil liegt im Be­triebs­auf­wand: Teams müssen Ka­pa­zi­täts­pla­nung, Patching, Re­ba­lan­cing, Backups, Security, Incident Response und Ob­ser­va­bi­li­ty selbst über­neh­men.

Cloud-native mit Ku­ber­netes

Immer häufiger wird Apache Kafka in Ku­ber­netes-Clustern betrieben. Dafür kommen Ope­ra­to­ren wie Strimzi zum Einsatz. Strimzi au­to­ma­ti­siert die Be­reit­stel­lung und Ver­wal­tung von Kafka auf Ku­ber­netes und bildet Kafka-Cluster, Topics, User, Kafka Connect und weitere Kom­po­nen­ten als Ku­ber­netes-Res­sour­cen ab.

Dieses Modell passt gut zu Cloud-nativen Um­ge­bun­gen, in denen An­wen­dun­gen, Stream-Pro­zes­so­ren und Platt­form­diens­te gemeinsam über Ku­ber­netes be­reit­ge­stellt werden. Neben selbst­ver­wal­te­ten Ku­ber­netes-Clustern kommen dafür auch Managed-Ku­ber­netes-Dienste infrage, etwa IONOS Managed Ku­ber­netes. Wichtig ist dabei, dass Kafka ein zu­stands­be­haf­te­tes System ist. Storage, Netzwerk, Ver­füg­bar­keit, Broker-Iden­ti­tä­ten und Res­sour­cen­li­mits müssen sorg­fäl­tig geplant werden.

Managed Services

Bei voll­stän­dig ver­wal­te­ten Angeboten wie Confluent Cloud übernimmt der Anbieter große Teile des Betriebs. Dazu gehören ty­pi­scher­wei­se Pro­vi­sio­nie­rung, Wartung, Upgrades, Aus­fall­si­che­rung, Mo­ni­to­ring und Ska­lie­rung. Für Teams ohne eigenes Kafka-Be­triebs­team kann ein Managed Service den Einstieg deutlich ver­ein­fa­chen.

Managed Kafka reduziert den ope­ra­ti­ven Aufwand, ersetzt aber nicht die Ar­chi­tek­tur­ar­beit. Topic-Design, Par­ti­tio­nie­rung, Retention, Schema-Go­ver­nan­ce, Zu­griffs­kon­trol­le, Da­ten­flüs­se und Consumer-Verhalten bleiben weiterhin Aufgaben des Ent­wick­lungs­teams. Außerdem sollten Kos­ten­mo­dell, Da­ten­re­si­denz, Netz­werk­pfa­de und mögliche An­bie­ter­ab­hän­gig­kei­ten geprüft werden.

Fazit

Apache Kafka ist heute weit mehr als eine Nach­rich­ten­war­te­schlan­ge. Die Plattform verbindet Event Streaming, Messaging, Stream Pro­ces­sing und Da­ten­in­te­gra­ti­on in einem ver­teil­ten System. Durch KRaft ist die Apache-Kafka-Ar­chi­tek­tur moderner und einfacher geworden, da Kafka seine Cluster-Metadaten ohne ZooKeeper selbst verwaltet.

Für Un­ter­neh­men, die Mi­cro­ser­vices ent­kop­peln, Da­ten­bank­än­de­run­gen in Echtzeit über­tra­gen, Da­ten­strö­me ver­ar­bei­ten oder eine Event-Driven Ar­chi­tec­tu­re aufbauen möchten, ist Apache Kafka eine zentrale Tech­no­lo­gie. Ent­schei­dend für den Erfolg sind jedoch ein klares Topic-Design, saubere Go­ver­nan­ce, passende Be­triebs­mo­del­le und ein gutes Ver­ständ­nis des Un­ter­schieds zwischen klas­si­schem Messaging und Event Streaming.