Wenn ein Webshop jede Bestellung sofort auswerten, gleichzeitig aber auch Monatsberichte über die gesamte Historie erstellen muss, reicht ein einzelner Datenverarbeitungspfad oft nicht aus. Die Lambda Architecture verbindet deshalb Batch- und Stream-Verarbeitung, damit aktuelle Ergebnisse schnell verfügbar sind und historische Daten trotzdem vollständig und korrekt neu berechnet werden können. Ich zeige, wie die drei Schichten funktionieren, welche Frameworks sich eignen und wann ein einfacheres Modell die bessere Wahl ist.
Die wichtigsten Entscheidungen auf einen Blick
- Zwei Verarbeitungspfade liefern gleichzeitig schnelle und gründlich berechnete Ergebnisse.
- Die Batch-Schicht verarbeitet die gesamte Historie und korrigiert Fehler.
- Die Speed-Schicht reagiert innerhalb von Sekunden oder Minuten auf neue Ereignisse.
- Eine Serving-Schicht stellt die kombinierten Ergebnisse für APIs, Dashboards und Frontends bereit.
- Der größte Nachteil ist doppelte Geschäftslogik in Batch- und Streaming-Pipelines.
Was hinter der Lambda-Architektur steckt
Die Lambda-Architektur ist ein Muster für Systeme, die große Datenmengen sowohl vollständig als auch nahezu in Echtzeit verarbeiten müssen. Neue Ereignisse laufen durch einen schnellen Stream-Pfad, während ein Batch-Prozess regelmäßig die komplette Datenbasis neu berechnet. Dadurch entsteht ein Kompromiss zwischen geringer Latenz und hoher Genauigkeit.
Ein typisches Ereignis kann ein Seitenaufruf, eine Bestellung, eine Zahlung oder eine Änderung im Benutzerkonto sein. Die Daten werden möglichst unverändert in einem dauerhaften Speicher abgelegt. Das ist wichtig, weil sich fehlerhafte Berechnungen später durch eine erneute Verarbeitung der Originaldaten korrigieren lassen.
Ich halte diesen Ansatz vor allem dann für sinnvoll, wenn ein Unternehmen zwei Dinge gleichzeitig braucht. Das Frontend soll aktuelle Informationen anzeigen, während Finance, Analytics oder Machine-Learning-Teams auf vollständig geprüfte historische Daten angewiesen sind. Für ein kleines Projekt mit wenigen Ereignissen pro Minute wäre die Architektur dagegen meist unnötig komplex.
Die Bezeichnung darf außerdem nicht mit AWS Lambda verwechselt werden. AWS Lambda ist ein Dienst für serverlose Funktionen, während die Lambda-Architektur ein allgemeines Konzept für Datenverarbeitung beschreibt.
So arbeiten die drei Schichten zusammen
Das Modell besteht klassisch aus einer Batch-Schicht, einer Speed-Schicht und einer Serving-Schicht. Beide Verarbeitungspfade greifen auf dieselbe Datenquelle zu, erzeugen aber zunächst unterschiedliche Sichten. Die Serving-Schicht führt diese Sichten für die Abfrage durch eine Webanwendung oder ein Dashboard zusammen.
Die Batch-Schicht schafft den verlässlichen Referenzstand
Die Batch-Schicht verarbeitet die gesamte Historie in größeren Intervallen, etwa stündlich, täglich oder nach einem geplanten Rechenlauf. Sie kann verspätete Ereignisse, nachträgliche Korrekturen und geänderte Berechnungsregeln berücksichtigen. Ihr Ergebnis gilt normalerweise als vollständig und belastbar, ist aber nicht sofort aktuell.
Als Speicher eignen sich häufig Objektspeicher wie S3-kompatible Systeme, Datenbanken für analytische Abfragen oder Tabellenformate wie Apache Iceberg und Delta Lake. Entscheidend ist weniger der konkrete Anbieter als die Möglichkeit, Rohdaten langfristig aufzubewahren und Verarbeitungsläufe reproduzierbar zu wiederholen.
Die Speed-Schicht reagiert auf neue Ereignisse
Die Speed-Schicht verarbeitet eingehende Daten fortlaufend. Sie berechnet beispielsweise die Zahl der aktiven Nutzer der letzten fünf Minuten oder aktualisiert den Warenkorbwert eines Kunden direkt nach einer Bestellung. Typische Zielwerte liegen bei wenigen Sekunden bis wenigen Minuten, abhängig von Datenmenge, Infrastruktur und gewünschter Genauigkeit.
Diese Schicht darf nicht mit einer einfachen Datenbankabfrage verwechselt werden. Bei laufenden Aggregationen braucht sie Zustände, Zeitfenster und eine Strategie für verspätete Ereignisse. Apache Flink arbeitet dafür unter anderem mit Event Time und Watermarks. So kann das System unterscheiden, wann ein Ereignis tatsächlich passiert ist und wann es verarbeitet wurde.
Lesen Sie auch: WordPress-Website erstellen - von der Planung bis zum sicheren Livegang
Die Serving-Schicht macht Ergebnisse nutzbar
Die Serving-Schicht stellt vorberechnete Daten für Anwendungen bereit. Eine Web-API sollte nicht jedes Mal Millionen Rohereignisse durchsuchen, wenn ein Nutzer ein Dashboard öffnet. Stattdessen liest sie aus einem dafür optimierten System wie Redis, PostgreSQL, ClickHouse oder Elasticsearch.
| Schicht | Aufgabe | Typische Aktualisierung | Beispiele |
|---|---|---|---|
| Batch | Gesamte Historie berechnen und korrigieren | Stündlich bis täglich | Spark, Iceberg, Delta Lake |
| Speed | Neue Ereignisse fortlaufend verarbeiten | Sekunden bis Minuten | Flink, Kafka Streams, Spark Structured Streaming |
| Serving | Ergebnisse für APIs und Dashboards liefern | Nahezu sofort | Redis, ClickHouse, PostgreSQL, Elasticsearch |
Bei einer Abfrage werden häufig der geprüfte Batch-Wert und die neueren Speed-Daten zusammengeführt. Ein Dashboard kann dann beispielsweise den Tagesumsatz aus der Batch-Schicht plus die letzten fünf Minuten aus dem Stream anzeigen. Die Schnittstelle muss diese Logik ausdrücklich kennen, sonst entstehen doppelte Zählungen oder widersprüchliche Werte.
Ein Praxisbeispiel aus der Webentwicklung
Stellen wir uns einen Onlinehändler mit einer personalisierten Startseite vor. Jede Aktion erzeugt ein Ereignis, etwa „Produkt angesehen“, „in den Warenkorb gelegt“ oder „Bestellung abgeschlossen“. Diese Ereignisse landen zunächst in einem Event-Stream und werden zusätzlich dauerhaft gespeichert.
Die Speed-Schicht aktualisiert sofort die meistgekauften Produkte, die Anzahl aktiver Warenkörbe und mögliche Betrugssignale. Das Frontend ruft diese Werte über eine REST- oder GraphQL-API ab. Für den Nutzer fühlt sich die Anwendung dadurch aktuell an, ohne dass die Datenbank bei jeder Anfrage komplexe Aggregationen durchführen muss.
In der Nacht verarbeitet die Batch-Schicht alle Ereignisse erneut. Dabei erkennt sie beispielsweise eine verspätet eingegangene Zahlung oder eine nachträgliche Stornierung. Die korrigierten Werte überschreiben die vorläufigen Ergebnisse. Gerade bei Umsatz, Lagerbestand und Abrechnung ist dieser Reconciliation-Schritt wichtiger als eine künstlich niedrige Latenz.
Eine saubere Webimplementierung trennt deshalb drei Verantwortlichkeiten. Der Event-Producer im Backend schreibt unveränderliche Ereignisse, die Verarbeitung erzeugt fachliche Sichten und die API liefert nur aufbereitete Ergebnisse. Ich sehe oft, dass Teams diese Ebenen direkt miteinander vermischen. Das funktioniert im Prototyp, wird aber bei Wiederholungen, Fehlerkorrekturen und steigender Last schnell unübersichtlich.
Welche Frameworks und Technologien sinnvoll sind
Die Technologieauswahl sollte von der benötigten Latenz und der Art der Daten abhängen, nicht vom bekanntesten Tool. Für viele Anwendungen reicht ein relativ überschaubarer Stack aus Event-Bus, dauerhaftem Speicher, Verarbeitungssystem und Abfragedatenbank.
- Apache Kafka oder Redpanda eignen sich als Ereignisprotokoll, das Daten partitioniert und zeitweise vorhält.
- Apache Flink passt zu zustandsbehafteter Verarbeitung, Event Time, komplexen Fenstern und niedriger Latenz.
- Spark oder Spark Structured Streaming sind attraktiv, wenn Batch- und Streaming-Verarbeitung eng zusammengehören.
- Airflow oder Dagster orchestrieren geplante Batch-Läufe, Abhängigkeiten und Wiederholungen.
- Iceberg oder Delta Lake helfen, große Datenbestände mit Schemaänderungen und historischen Versionen zu verwalten.
- ClickHouse, PostgreSQL, Redis oder Elasticsearch bedienen unterschiedliche Abfragemuster in der Serving-Schicht.
Besondere Aufmerksamkeit verdienen Idempotenz und Duplikate. Eine idempotente Verarbeitung kann dasselbe Ereignis mehrfach erhalten, ohne das Ergebnis falsch zu erhöhen. Dazu gehören stabile Event-IDs, Wiederholungslogik und klare Regeln für Korrekturen.
Auch die Zeitsemantik wird oft unterschätzt. Bei einem internationalen Webshop kann ein Ereignis mehrere Minuten verspätet eintreffen. Wer nur die Serverzeit verwendet, erhält möglicherweise falsche Tages- oder Stundenwerte. Event Time, Watermarks und definierte Regeln für verspätete Daten sind deshalb keine akademischen Extras, sondern praktische Bestandteile eines zuverlässigen Systems.
„Exactly once“ klingt ebenfalls eindeutiger, als es in der Praxis ist. Selbst wenn der Stream-Prozessor eine Verarbeitung genau einmal garantiert, können nachgelagerte Datenbanken oder externe APIs andere Eigenschaften haben. Ich plane deshalb lieber mit kontrollierter Wiederholbarkeit, Transaktionsgrenzen und überprüfbaren Geschäftsschlüsseln, statt mich allein auf ein Schlagwort zu verlassen.
Lambda oder Kappa für neue Projekte
Die klassische Lambda-Architektur hat einen offensichtlichen Preis. Die Batch- und die Streaming-Schicht enthalten häufig ähnliche Geschäftslogik, müssen aber getrennt betrieben, getestet und überwacht werden. Schon kleine Unterschiede bei Rundungen, Zeitfenstern oder Filtern können dazu führen, dass zwei Schichten verschiedene Ergebnisse liefern.
| Kriterium | Lambda-Architektur | Kappa-Architektur |
|---|---|---|
| Verarbeitung | Batch und Stream parallel | Ein primärer Stream-Pfad |
| Historische Korrekturen | Neuaufbau über Batch | Replay des Ereignisprotokolls |
| Codebasis | Oft doppelte Logik | Weniger Duplikation |
| Stärke | Robuste Vollberechnung | Einfacherer Datenpfad |
| Risiko | Höhere Betriebs- und Testkomplexität | Hohe Anforderungen an Retention und Replay |
Eine Kappa-Architektur behandelt auch historische Daten als Stream und berechnet sie bei Bedarf durch Replay erneut. Das kann die Codebasis vereinfachen, setzt aber ein dauerhaft verfügbares Ereignisprotokoll, ausreichende Speicherdauer und einen leistungsfähigen Streaming-Prozessor voraus.
Moderne Plattformen verwischen die Grenze zunehmend. Spark Structured Streaming kann dieselbe Logik je nach Quelle und Ausführung als Batch oder Stream verwenden. Auch Flink verarbeitet sowohl begrenzte als auch unbegrenzte Datenströme. Das bedeutet jedoch nicht, dass jede Anwendung automatisch einfacher wird. Ein einheitliches Framework ersetzt keine klare Daten- und Fehlerstrategie.
Ich würde Lambda wählen, wenn eine vollständige Neuverarbeitung fachlich wichtig ist, Streaming und Batch unterschiedliche Optimierungen brauchen oder bestehende Systeme bereits getrennt arbeiten. Für ein neues Produkt mit gut definierten Ereignissen und langer Retention ist ein streamzentriertes Modell oft schlanker. Bei einfachen Analyseanforderungen genügt sogar ein regelmäßiger Batch-Job.
Die häufigsten Fehler beim Aufbau
Der erste Fehler ist, die Speed-Schicht als endgültige Wahrheit zu behandeln. Sie liefert schnelle Ergebnisse, kann aber verspätete oder korrigierte Ereignisse noch nicht kennen. Ein sichtbarer Hinweis wie „vorläufig“ oder ein klar definierter Aktualisierungszeitpunkt schafft hier mehr Vertrauen als eine scheinbar exakte Zahl.
Der zweite Fehler liegt in fehlenden Verträgen für Ereignisse. Jedes Event sollte mindestens eine eindeutige ID, einen Zeitstempel, einen Typ, eine Version und die fachlich relevanten Schlüssel enthalten. Ohne Schema-Versionierung werden Änderungen im Backend schnell zu stillen Fehlern in alten Pipelines.
Problematisch ist auch eine zu spät geplante Beobachtbarkeit. Metriken wie Durchsatz, Consumer-Lag, verspätete Ereignisse, Fehlerraten und Abweichungen zwischen Batch- und Speed-Ergebnis sollten von Anfang an sichtbar sein. Ein Alarm nur bei abgestürzten Prozessen reicht nicht aus, weil eine Pipeline auch laufen und trotzdem falsche Daten liefern kann.
- Geschäftslogik nicht unkontrolliert in zwei Implementierungen kopieren.
- Rohdaten unverändert und ausreichend lange speichern.
- Wiederholungen, Duplikate und verspätete Events bewusst testen.
- Batch- und Speed-Ergebnisse regelmäßig gegeneinander prüfen.
- Die Serving-Datenbank nach Abfragemuster und nicht nach Teamgewohnheit auswählen.
Die richtige Architektur beginnt mit der Latenzfrage
Für die Entscheidung genügt meist eine nüchterne Frage. Muss der Nutzer innerhalb von Sekunden einen vorläufigen Wert sehen, während später eine vollständig korrigierte Berechnung erfolgt? Wenn ja, kann die Lambda-Architektur ihren zusätzlichen Aufwand rechtfertigen. Wenn nicht, ist ein Batch- oder streamzentriertes Modell meist leichter zu betreiben.
Mein praktischer Rat lautet, zuerst ein einziges wichtiges Ereignis Ende zu Ende zu verfolgen. Dabei sollten Speicherung, Verarbeitung, API, Fehlerwiederholung und fachliche Korrektur funktionieren, bevor weitere Frameworks hinzukommen. Eine kleinere, überprüfbare Pipeline ist langfristig wertvoller als ein beeindruckendes Diagramm mit zu vielen Schichten.
Die Stärke dieses Musters liegt nicht darin, jede Datenaufgabe in Echtzeit zu lösen. Sie liegt in der bewussten Trennung zwischen schneller Reaktion und verlässlicher Neuberechnung. Wer diese beiden Ziele sauber verbindet, erhält eine belastbare Grundlage für Webanwendungen, Analytics und KI-gestützte Funktionen.
