Ist Apache Iggy ein schnelleres Kafka? Klingt einfach, ist es aber nicht. Beide Systeme verwalten Nachrichten in partitionierten, append-only Logs. Offsets, Consumer Groups, Replay – alles da. Doch bei der Frage, was eine „bestätigte Nachricht“ tatsächlich bedeutet, gehen die Wege auseinander.
Iggy ist eine Streaming-Plattform in Rust, im August 2026 vom Apache Incubator zum Top-Level-Projekt aufgestiegen. Piotr Gankiewicz hatte das Projekt Anfang 2023 begonnen, um Rust zu lernen. Der Name steht für Italienischer Windhund – kleiner, extrem schneller Hund. Die Herkunft erklärt einiges, aber nicht alles.
Iggy und Kafka teilen sich das Datenmodell
Iggy will das Event-Log nicht durch eine andere Abstraktion ersetzen. Wer mit Kafka gearbeitet hat, kennt das Speichermodell. Ein Iggy-Stream ist die oberste Ebene, darunter Topics und Partitionen. Jede Partition ist ein append-only Log mit Segmenten, Nachrichten haben Offsets. Ein Consumer lässt sich ab einem expliziten Offset, einer Zeitmarke, dem Anfang oder Ende des Logs starten oder ab der gespeicherten Consumer-Position des Servers.
Damit unterscheidet sich der Vergleich von Systemen wie Apache Fluss, die das Event-Log durch eine Datenbank oder Streaming-Tabelle ersetzen. Iggy behauptet nicht, Kafkas Abstraktion sei falsch. Es fragt, ob man dieselbe Abstraktion anders umsetzen kann. Genau dort wird es interessant: in den Entscheidungen unter der Haube.
Thread-per-Core statt JVM: Iggys Architektur
Kafka hat seinen Speicherpfad über Jahre optimiert: sequentielles Schreiben, aggressives Batching, OS-Page-Cache, Zero-Copy beim Ausliefern. Die Strategie: dem Betriebssystem nicht in die Quere kommen. Iggy geht einen anderen Weg. Seit Version 0.6.0 nutzt der Server eine Thread-per-Core-Architektur mit der compio-Runtime, die auf Linux mit io_uring arbeitet. Partitionen werden CPU-gepinnten Shards zugeordnet. Statt eines Work-Stealing-Executors, der Tasks zwischen Threads schiebt, hält jeder Shard seinen Teil der Last und läuft auf einem festen Core.
Dazu unterhält Iggy einen eigenen, vorab allokierten Speicherpool und nutzt Vectored-I/O, um Nachrichtenpuffer gebündelt auf die Festplatte zu schreiben. Das Ziel: Vorhersagbarkeit. Bei Thread-per-Core wandert eine heiße Partition nicht durch alle Worker-Threads. Weniger Synchronisation im Datenpfad, weniger Cache-Invalidierung, weniger Allokationen. Das Projekt berichtet von deutlichen Verbesserungen bei den Tail-Latenzen.
Wichtig dabei: Kafka ist keine Anwendung, die ständig Nachrichtenobjekte allokiert. Ein großer Teil seiner Leistung kommt daher, den Payload in Ruhe zu lassen und dem Betriebssystem Caching und sequentielle I/O zu überlassen. Der Unterschied ist also nicht „Kafka ist langsam, Iggy ist schnell“, sondern: Kafka delegiert Speicher-Caching an den OS-Kernel, Iggy versucht, Ausführung und Speicherpfad selbst zu steuern.
Wann ist eine Nachricht wirklich sicher?
Hier wird es heikel für pauschale Leistungsvergleiche. Der Schreibpfad von Iggy vereinfacht: Nachrichten werden gepuffert, bis eine konfigurierbare Anzahl oder Größe erreicht ist – aktuell standardmäßig 1024 Nachrichten oder 1 MiB. fsync ist pro Topic einstellbar. Eine akzeptierte Schreiboperation und eine durable Schreiboperation sind nicht dasselbe.
Iggys Dokumentation stellt klar: Die Standardkonfiguration für einzelne Knoten bietet nur geringe Haltbarkeitsgarantien. Bei einem Crash oder Stromausfall können Nachrichten verloren gehen, wenn man die Haltbarkeits-Einstellungen nicht erhöht. Der Server stellt enforce_fsync und Flush-Schwellen zur Steuerung dieses Kompromisses bereit. Kafka hat dasselbe Grundproblem, aber eine andere Lösung. Kafka ruft nicht für jede Nachricht fsync auf, sondern verlässt sich für Produktions-Haltbarkeit in der Regel auf Replikation.
Eine Bestätigung des Producers bedeutet bei Kafka normalerweise mehr als „der Leader hat meine Schreiboperation angenommen“. Kafka pflegt den ISR – die Menge der synchronen Replikate, also Replikate, die mit dem Leader aufgeholt sind. Mit acks=all wird eine Schreiboperation erst bestätigt, wenn sie alle über min.insync.replicas festgelegten Replikate dieser Gruppe erreicht hat. Das macht einen Unterschied, wenn du Latenzen vergleichst. Ein Iggy-Producer, der auf eine lokale Schreiboperation wartet, und ein Kafka-Producer, der auf Replikation auf eine andere Maschine wartet, messen nicht dasselbe.
Was die veröffentlichten Zahlen wirklich aussagen
Für diesen Vergleich wurde bewusst kein eigenes Benchmark zwischen Kafka und Iggy durchgeführt. Die Zahlen aus dem Iggy-Projekt sind trotzdem lesenswert – vor dem Hintergrund aus dem letzten Abschnitt. In den FAQ berichtet das Projekt, die Thread-per-Core-Umstellung habe eine bis zu 92 Prozent bessere P9999-Tail-Latency und 18 Prozent mehr Durchsatz bei aktiviertem fsync gebracht. Die Website spricht von Millionen Nachrichten pro Sekunde mit Sub-Millisekunden-Tail-Latenzen auf einem einzelnen Knoten.
Das sind plausible Zahlen für das, was sie messen: die Effizienz einer Single-Node-Log-Engine unter Iggys eigenen Bestätigungs-Semantiken. Kein vollständiger Äpfel-zu-Äpfel-Vergleich mit Kafka. Solange Iggys erste Replikationsversion nicht ausgeliefert ist, lässt sich replizierte Haltbarkeit nicht gegen ein System ohne Replikation testen. Einzelknoten-Vergleiche sind möglich, Dritte haben sie veröffentlicht. Ein kürzlich von einem kommerziellen Iggy-Anbieter publiziertes Broker-Benchmark sieht Iggy bei Durchsatz und Tail-Latency deutlich vor Kafka. Trotzdem ist ein solcher Test nur aussagekräftig, wenn beide Systeme auf demselben Haltbarkeitspunkt sitzen: gepufferter Schreibvorgang, lokales fsync oder synchrone Replikation.
Kafka mit acks=all und drei Replikaten gegen einen einzelnen Iggy-Knoten mit Standard-Flush erzählt dir vor allem, dass die beiden Setups unterschiedliche Ausfälle überleben. Genau deshalb ist die P9999-Verbesserung interessant: Sie zeigt, was die Thread-per-Core-Umschreibung gegen Iggys eigene frühere Architektur gebracht hat. Bei diesem Vergleich bleibt wirklich alles andere konstant.
Replikation: Der große Unterschied und der Blick nach vorn
Lange war der ehrliche Vergleich kurz: Kafka hat Replikation, Iggy nicht. Das ändert sich gerade. Die Multi-Node-Clusterung basiert auf Viewstamped Replication (VSR) und ist im neuen Servercode bereits vorhanden. Im August 2026 wurde server-ng als Haupt-iggy-server übernommen, erste 0.9.0-edge-Builds erschienen. Laut Projekt ist die Serverseite weitgehend fertig: View Changes, State Transfer, Leader-Forwarding, Client-Session-Recovery, Node-Authentifizierung, TLS zwischen den Knoten und deterministische Simulationstests für Crashes und Netzwerkpartitionen sind implementiert.
Die verbleibende Arbeit liegt vor allem darin, alle SDKs auf das VSR-Wire-Protocol zu migrieren und gegen den Cluster-Server zu testen. Eine nützliche Unterscheidung: Replikation ist keine bloße Roadmap-Idee mehr, aber die erste stabile Version mit Replikation ist noch nicht erschienen. Die neueste offizielle stabile Version bleibt 0.8.0, obwohl 0.9.0 bereits durch Edge-Artefakte sichtbar ist. Der Unterschied zwischen Kafka und Iggy verschiebt sich damit von Existenz zu Reife. Kafkas Replikationsmodell läuft seit über einem Jahrzehnt in realen Systemen. Iggys VSR-Cluster nähert sich erst seiner ersten stabilen Version.
VSR ist durchaus eine ernstzunehmende Designentscheidung. Deterministische Simulationstests sind dieselbe Disziplin, mit der Projekte wie FoundationDB und TigerBeetle Vertrauen in ihren Konsenscode aufbauen. Wer das von Anfang an berücksichtigt, hat Ambitionen. Trotzdem sind eine Implementierung vor der ersten stabilen Version und ein System, das durch Produktionsausfälle geformt wurde, unterschiedliche Dinge. Für eine Produktionsentscheidung heute zählt diese Reifedifferenz mehr als die Frage, ob VSR auf dem Papier sauberer aussieht als Kafkas ISR-Modell.
Geht es um den Ausfall eines ganzen Rechenzentrums, wird Kafkas gesammelte Maschinerie zum Feature. broker.rack erlaubt es, Replikate über Racks zu verteilen. Iggy muss hier aufholen, und es bleibt abzuwarten, wie sich die VSR-Implementierung unter realen Bedingungen schlägt. Der aktuelle Stand: Die Systeme stimmen in der grundlegenden Datenmodell-Vorstellung überein, aber die Implementierungsentscheidungen führen zu unterschiedlichen Kompromissen. Für dich als Nutzer heißt das: Bevor du dich entscheidest, musst du genau definieren, welchen Ausfall deine bestätigte Nachricht überleben soll. Dann lässt sich beurteilen, ob das schnellere System wirklich das bessere ist.
Quelle: softwaremill.com
