Kappa-Architecture: Definition und Abgrenzung zu Lambda

Die Kappa-Architecture ist ein Bauplan für Datensysteme, der aktuelle Auswertungen (in Echtzeit) und Rückblicke auf ältere Daten über denselben Datenstrom (kontinuierlichen Fluss von Ereignissen) bedient, ohne einen zweiten, parallelen Verarbeitungsweg für die Historie. Der Ansatz wurde 2014 von Jay Kreps als vereinfachte Alternative zur älteren Lambda-Architecture vorgeschlagen, die noch zwei getrennte Pfade (einen für Echtzeit, einen für den Massen-Abgleich) parallel betreibt.

Was ist Kappa-Architecture?

Die zentrale Idee ist ein Ereignis-Log: eine geordnete, unveränderliche Liste aller Vorgänge, die im System passieren, vergleichbar mit einem Kassenbuch, in das nur unten angehängt und nichts nachträglich korrigiert wird. Alle Auswertungen lesen aus genau dieser Liste. Rückblicke auf ältere Daten entstehen nicht über einen zweiten Weg, sondern indem dieselbe Auswertungs-Logik einfach noch einmal vom Anfang der Liste durchläuft (Replay, also Wiederabspielen). Sobald sich die Logik oder das Ergebnis-Format ändert, wird schlicht neu abgespielt. Ein separater Nacht-Rechenlauf (Batch-Layer) entfällt.

Jay Kreps hat den Begriff [2014 in einem Blogpost auf O'Reilly Radar](https://www.oreilly.com/radar/questioning-the-lambda-architecture/) geprägt. Sein Argument: Die Lambda-Architecture nach Nathan Marz verlangt die parallele Pflege zweier unterschiedlicher Verarbeitungspfade (Batch und Speed) mit doppelter Code-Basis und doppelter Betriebs-Verantwortung. Wenn eine ausreichend leistungsfähige Streaming-Engine denselben Datensatz sowohl in Echtzeit als auch beim Backfill in vertretbarer Zeit verarbeiten kann, ist der Batch-Pfad überflüssig. Die Kappa-Architecture ist also weniger ein neues Design als der Verzicht auf eine Schicht.

Der typische Aufbau besteht aus drei Komponenten. Ein unveränderlicher Log-Store hält die Ereignisse in fester Reihenfolge und mit langer Retention, üblicherweise [Apache Kafka](https://kafka.apache.org/documentation/), Amazon Kinesis oder Apache Pulsar. Eine Stream-Processing-Engine liest den Log kontinuierlich und berechnet die abgeleiteten Ergebnisse; verbreitet sind Apache Flink, Kafka Streams und [Spark Structured Streaming](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html). Ein Serving-Layer stellt die Ergebnisse für Queries oder nachgelagerte Systeme bereit.

Damit das Modell trägt, müssen einige Bedingungen erfüllt sein. Das Log muss lang genug vorgehalten werden, damit ein Replay auch mehrere Monate oder Jahre zurückreichen kann. Die Verarbeitung muss deterministisch sein, damit ein Replay dasselbe Ergebnis erzeugt. Und die Streaming-Engine muss genügend Durchsatz haben, um einen vollständigen Backfill in einem betrieblich sinnvollen Zeitraum zu leisten.

Abgrenzung: Lambda, Medallion und klassische Batch-Analytics

Die Kappa-Architecture wird häufig mit benachbarten Konzepten verwechselt. Die folgende Tabelle klärt die drei zentralen Verwechslungen.

Begriff	Verhältnis zu Kappa-Architecture
Lambda-Architecture	zwei parallele Pfade (Batch-Layer für vollständige Historie, Speed-Layer für Latenz) mit Merge im Serving-Layer; Kappa entfernt den Batch-Layer und ersetzt ihn durch Log-Replay
Medallion-Architecture	mehrstufiges Qualitäts-Schichtenmodell (Bronze, Silver, Gold) auf einem Lakehouse; orthogonaler Frame, orientiert am Verarbeitungsgrad statt an der Trennung Batch/Stream, und mit Kappa-Verarbeitung kombinierbar
Klassische Batch-Analytics	geplante Läufe auf endlichen Datensätzen ohne Streaming-Kontinuität; das Gegenmodell zu Kappa, das Historie und Echtzeit in einer Streaming-Semantik zusammenfasst
Zero-ETL / CDC-Pipelines	Replikationsmuster zwischen Systemen, orthogonal zur Wahl Kappa/Lambda; CDC ist eine typische Ereignisquelle in einer Kappa-Pipeline

Die Abgrenzung zu Lambda ist die wichtigste. Beide Ansätze lösen dasselbe Problem (Echtzeit und historische Wahrheit in einer Architektur), aber mit verschiedenen Kosten: Lambda verdoppelt Code und Betriebslast, Kappa verlangt lange Log-Retention und ausreichenden Replay-Durchsatz.

Beispiel: Session-Kennzahlen auf einem E-Commerce-Log

Ein E-Commerce-Betrieb schreibt Click- und Transaktions-Ereignisse in ein Kafka-Topic mit einer Retention von zwölf Monaten. Ein Structured-Streaming-Job liest das Topic kontinuierlich, berechnet Session-Kennzahlen wie aktive Nutzer pro Stunde, Warenkorb-Wert und Konversionsrate und schreibt die Ergebnisse in eine Serving-Tabelle für das BI-Dashboard.

Wird die Kennzahl-Logik geändert, etwa weil eine neue Session-Definition eingeführt wird, wird derselbe Job gegen den Log-Anfang neu gestartet. Das Ergebnis-Set wird vollständig neu aufgebaut, ohne dass ein separater Batch-ETL für die Historie betrieben werden muss. Weitere verbreitete Einsatzfelder sind IoT-Telemetrie mit langer Retention, Betrugserkennung auf Zahlungsströmen und Netzwerk-Analytik im Telekommunikations-Umfeld.