Kappa Architecture
Einleitung
Kappa Architecture ist ein Datenverarbeitungsansatz, bei dem Streaming der einzige Verarbeitungspfad ist.
Im Gegensatz zur Lambda-Architektur gibt es:
- keinen separaten Batch-Layer
- keinen separaten Speed-Layer
Stattdessen basiert alles auf:
einem persistenten, wiederabspielbaren Event-Log.
Kappa ist keine „Realtime-Spielerei“,
sondern eine Vereinfachungsstrategie.
Einordnung
Kappa ist eine Stream- und Datenarchitektur.
Sie beschreibt:
- wie Daten gespeichert werden (append-only Log)
- wie sie verarbeitet werden (Streaming-Jobs)
- wie historische Neuberechnung erfolgt (Replay)
Sie ist besonders relevant in:
- Event-Driven-Architekturen
- Streaming-Plattformen
- Analytics- und Near-Realtime-Systemen
Ursprung
Kappa wurde von Jay Kreps als Alternative zur Lambda-Architektur formuliert.
Lambda bestand aus:
- Batch-Layer (historische Berechnung)
- Speed-Layer (Realtime)
- Serving-Layer
Problem:
- Doppelte Logik
- Zwei Codepfade
- Zwei Fehlerquellen
Kappa reduzierte das auf:
Ein Log. Ein Verarbeitungspfad.
Grundprinzip
Kernaussage:
- Alles ist ein Stream
- Historie bleibt im Log erhalten
- Reprocessing = erneutes Abspielen
Architekturprinzipien
1️⃣ Append-Only Log
- Daten werden nicht überschrieben
- Ereignisse sind immutable
- Historie bleibt vollständig erhalten
Das Log wird zur Quelle der Wahrheit.
2️⃣ Einziger Verarbeitungspfad
Es existiert nur:
- eine Streaming-Pipeline
- ein Berechnungsmodell
- ein Codepfad
Kein paralleler Batch-Stack.
3️⃣ Replay statt Batch
Historische Korrekturen erfolgen durch:
- Reset des Consumers
- Reprocessing des Logs
- Neuer Aufbau der Materialized Views
Vorteile
- Weniger Systemkomplexität als Lambda
- Kein doppelter Codepfad
- Einheitliche Logik
- Natürliche Rebuild-Möglichkeit
- Gute Integration mit Event-Driven-Systemen
Risiken / Fallstricke
1️⃣ Streaming-Infrastruktur als Single Point of Truth
Wenn das Log instabil ist, ist das gesamte System instabil.
Kappa setzt voraus:
- hochverfügbare Broker
- starke Partitionierungsstrategie
- saubere Retention-Regeln
2️⃣ Reprocessing-Kosten
Große Logs bedeuten:
- hohe Rebuild-Zeiten
- Infrastrukturkosten
- komplexe State-Management-Fragen
Replay ist einfach im Prinzip – aber teuer bei Petabyte-Daten.
3️⃣ Nicht alle Workloads sind Streams
Kappa ist ungeeignet für:
- reine Batch-Analysen
- große periodische Aggregationen
- Workloads ohne Event-Charakter
Vergleich: Lambda vs. Kappa
| Kriterium | Lambda | Kappa |
|---|---|---|
| Verarbeitungspfade | Batch + Stream | Nur Stream |
| Code-Komplexität | hoch | geringer |
| Infrastruktur | komplex | streaming-zentriert |
| Reprocessing | Batch | Replay |
| Eignung für Realtime | gut | sehr gut |
Lambda ist robuster bei starkem Batch-Fokus. Kappa ist eleganter bei Stream-Fokus.
Organisatorische Implikationen
Kappa erfordert:
- Event-Governance
- Schema-Versionierung
- Idempotente Verarbeitung
- Stateful Stream Processing
- Observability auf Pipeline-Ebene
Ohne diese Grundlagen wird das System schwer wartbar.
Eignung 2026
Geeignet bei:
- Event-Driven-Systemen
- Realtime-Analytics
- IoT- oder Clickstream-Szenarien
- Plattformen mit starkem Streaming-Fokus
- Teams mit Stream-Engineering-Kompetenz
Weniger geeignet bei:
- Dominantem Data-Warehouse-Reporting
- Geringem Realtime-Bedarf
- Fehlender Streaming-Infrastruktur
- Geringem Reifegrad in Event-Governance
Praxis-Check
Szenario 1: Echtzeit-Analytics
User-Events werden kontinuierlich verarbeitet. Fehler in Aggregationen werden durch Replay korrigiert.
Kappa passt.
Szenario 2: Klassisches Reporting
Tägliche Batch-Jobs dominieren. Historische Datenmengen sind sehr groß.
Lambda oder klassisches Batch-Modell ist oft stabiler.
Fazit
Kappa Architecture ist:
- eine Vereinfachung von Lambda
- eine Streaming-first-Strategie
- eng verbunden mit Event-Driven-Denken
Sie funktioniert gut, wenn:
Streaming die dominante Realität ist.
Sie ist kein Default für jede Datenplattform – sondern eine bewusste Architekturentscheidung.