Tansu schlägt vor, das Kafka-Modell neu zu strukturieren: den Zustand (State) aus den Brokern zu entfernen und die Zuverlässigkeit an einen externen Speicher zu delegieren. Dies verändert das Systemverhalten unter Last und vereinfacht das Betriebsmodell.
Das Problem zeigt sich auf der Betriebsebene. Ein klassischer Kafka-Broker ist eine Stateful-Komponente: Replikation, Leader Elections, persistenter Zustand, lange Laufzeiten. Solche Knoten lassen sich nur schwer herunterskalieren, sie erfordern Konfiguration und Ressourcen (z. B. Gigabytes an Heap). Das System ist aufgrund seiner internen Komplexität ausfallsicher. Das funktioniert, solange das Team bereit ist, den operativen Aufwand in Kauf zu nehmen und die Cluster „always on“ zu halten.
Tansu ändert diese Prämisse. Anstatt der Replikation innerhalb der Broker wird davon ausgegangen, dass der Speicher bereits die Durability gewährleistet. Die Broker werden stateless (zustandslos): ohne Leader, ohne lokalen Zustand, mit einem Speicherbedarf im Bereich von zweistelligen Megabytes. Sie können auf null skaliert und in Millisekunden hochgefahren werden. Dies ist ein Kompromiss: Die Ausfallsicherheit liegt nicht mehr in der Broker-Schicht, sondern im gewählten Backend-Speicher. Die Zuverlässigkeit des Systems hängt nun von den Eigenschaften von S3, Postgres oder einem anderen Backend ab.
Die Implementierung basiert auf Pluggable Storage. Das Backend wird über eine URL definiert:
- S3-kompatible Speicher — für einen komplett „diskless“ Modus
- SQLite — für lokale Entwicklung und Tests
- Postgres — für die Integration mit Streaming und Transaktionen
Im Fall von Postgres vereinfacht sich die Architektur auf DB-Primitive: Produce ist ein INSERT oder COPY, Fetch ist ein SELECT. Der Engpass waren sequentielle INSERTs aufgrund des Round-Trips für jeden Datensatz. Dies wurde durch COPY FROM ersetzt: ein einziges Setup, ein COPY DATA-Stream, ein abschließendes COPY DONE. Dieser Modus beseitigt die Bestätigungen für jeden einzelnen Datensatz und erhöht den Throughput bei Batch-Writes.
Zusätzlich entfällt die Notwendigkeit einer Transactional Outbox. Eine Nachricht und Geschäftsdaten können über eine Stored Procedure atomar in einer einzigen Transaktion geschrieben werden. Dies beseitigt die typische Lücke zwischen Datenbank und Broker.
Die Schema-Validierung wird in den Broker verlagert. Bei Kafka erfolgt diese normalerweise auf der Client-Seite und ist optional. Bei Tansu validiert der Broker jeden Datensatz (Avro, JSON, Protobuf) vor dem Schreiben. Das verlangsamt die Verarbeitung (Entpacken und Validieren ist erforderlich), garantiert aber clientunabhängig die Konsistenz. Derselbe Mechanismus ermöglicht es, Daten direkt in Analyseformate (Iceberg, Delta, Parquet) zu schreiben. Über ein „Sink Topic“ kann die Zwischenspeicherung umgangen und Tabellen direkt erstellt werden.
Als Proxy kann Tansu vor einem Kafka-Cluster platziert werden. Es werden ~60k Datensätze pro Sekunde und eine P99-Latenz von unter einer Millisekunde auf bescheidener Hardware bei einem Verbrauch von etwa 13 MB RAM angegeben. Dies zeigt, dass eine Stateless-Schicht leichtgewichtig sein kann, wenn ihr die Speicherverantwortung entzogen wird.
Das Fazit ist eine Verlagerung der Verantwortung. Der Broker wird zu einer zustandslosen Compute-Schicht. Der Speicher ist die Source of Truth. Operativ vereinfacht dies die Skalierung und das Deployment (bis hin zu minimalen Containern ohne Betriebssystem). Es entstehen jedoch neue Abhängigkeiten: Die Speichereigenschaften, dessen Latenz und Einschränkungen beeinflussen das Systemverhalten direkt. Einige Kafka-Funktionen fehlen derzeit noch (z. B. Throttling, ACL, Compaction für S3), was die Anwendungsszenarien einschränkt.
Der Ansatz erscheint als pragmatische Vereinfachung für Umgebungen, in denen der externe Speicher bereits eine zuverlässige und verwaltete Komponente ist.