Der Satz fällt in fast jedem Projekt: „Das muss in Echtzeit passieren." Dahinter steckt selten eine geprüfte Anforderung, sondern die berechtigte Erfahrung, dass Daten zu spät kommen. Die Antwort darauf ist aber nicht automatisch eine Streaming-Architektur — sondern erst einmal eine ehrliche Zahl.
Die einzige Frage, die zählt
Nicht „Wie schnell könnten wir?", sondern: Welche Entscheidung hängt an diesen Daten, und was kostet eine Verzögerung von einer Minute, einer Stunde, einem Tag? Diese Frage lässt sich für jeden Datenfluss beantworten und liefert eine belastbare Latenzanforderung.
- Ein Umsatzreport, der morgens gelesen wird: Tageslatenz genügt.
- Ein Lagerbestand für den Onlineshop: Minutenlatenz genügt meist, solange Überverkäufe abgefangen werden.
- Ein eingehender Lead, der binnen fünf Minuten angerufen werden soll: Sekunden bis wenige Minuten.
- Eine Zahlungsfreigabe mit Betrugsprüfung: echte Sekundenanforderung, ohne Alternative.
Erst wenn die Zahl steht, wird die Architektur ausgewählt — nicht umgekehrt.
Die drei Stufen
Batch: Daten werden in festen Intervallen verarbeitet, klassisch nachts oder stündlich. Vorteile: einfache Fehlersuche, einfache Wiederholbarkeit, klare Zeitfenster für schwere Berechnungen. Ein fehlgeschlagener Lauf wird schlicht wiederholt.
Micro-Batch: derselbe Mechanismus in kurzen Intervallen — alle ein bis fünf Minuten. Für die überwiegende Mehrheit der Geschäftsanforderungen ist das der Sweet Spot: gefühlt „live", technisch aber weiterhin ein Batch mit allen Vorteilen bei Betrieb und Nachvollziehbarkeit.
Streaming: Ereignisse werden einzeln verarbeitet, sobald sie entstehen. Das ist die einzige Option für echte Sekundenanforderungen — und die mit Abstand teuerste im Betrieb.
Faustregel: Wenn die Anforderung mit „ungefähr alle paar Minuten" erfüllt ist, gewinnt Micro-Batch. Streaming lohnt sich erst, wenn eine Verzögerung von Minuten echten, benennbaren Schaden verursacht.
Was Streaming wirklich kostet
Der Aufwand liegt nicht im Bauen, sondern im Betreiben. Dazu gehören ein Nachrichtenbroker mit Aufbewahrungsstrategie, Zustandshaltung über Zeitfenster hinweg, definierte Wiederaufsetzpunkte nach Ausfällen, ein Umgang mit verspäteten und doppelten Ereignissen sowie Monitoring, das den Rückstand (Lag) sichtbar macht. Dazu kommt die anspruchsvollste Disziplin: Idempotenz. In verteilten Systemen wird jede Nachricht irgendwann doppelt zugestellt — Verarbeitungen müssen das folgenlos überstehen.
Hinzu kommt die Fehlersuche: Ein Batch-Lauf lässt sich reproduzieren, ein Stream nicht ohne Weiteres. Wer keinen Wiedergabemechanismus für vergangene Ereignisse hat, debuggt im Blindflug.
Der pragmatische Mittelweg
In der Praxis bewährt sich eine gemischte Architektur: Der Kernbestand wird per Batch geladen — vollständig, geprüft, wiederholbar. Für die wenigen Ereignisse mit echter Zeitkritik läuft daneben ein schmaler Ereignispfad, meist über Webhooks oder eine Warteschlange. Beide schreiben in dieselbe Zielstruktur, wobei der Batch die Wahrheit korrigiert, falls der schnelle Pfad einmal etwas verpasst hat.
Das Ergebnis: Der Vertrieb bekommt seinen Lead in Sekunden, das Reporting bleibt konsistent, und der Betrieb muss nicht zwei vollständige Streaming-Plattformen beherrschen.
Woran man erkennt, dass die Entscheidung falsch war
- Zu viel Streaming: Das Team verbringt mehr Zeit mit Broker-Betrieb, Lag-Alarmen und Duplikaten als mit Fachlogik. Die Zahlen im Dashboard weichen von der Datenbank ab, und niemand kann den Zustand von gestern rekonstruieren.
- Zu viel Batch: Mitarbeitende bauen sich Schattenprozesse, weil sie nicht bis zum nächsten Lauf warten können — Excel-Exporte, manuelle Kopien, Zurufe.
Beides ist teuer, aber unterschiedlich sichtbar. Die Streaming-Rechnung kommt vom Betrieb, die Batch-Rechnung von den Menschen im Prozess.
Die Reihenfolge, die sich bewährt
Erst die Latenzanforderung je Datenfluss schriftlich festhalten. Dann mit dem einfachsten Verfahren starten, das sie erfüllt — im Zweifel Micro-Batch. Erst wenn die gemessene Verzögerung nachweislich Geld kostet, wird der betroffene Pfad auf Ereignisverarbeitung umgestellt, und zwar nur dieser. Architektur ist keine Haltung, sondern eine Antwort auf eine Zahl.
Was in die Anforderung gehört
Formulieren Sie Latenz messbar, sonst wird sie im Projekt zur Meinungsfrage. Ein brauchbarer Satz lautet: „95 Prozent der eingehenden Anfragen sind spätestens 60 Sekunden nach Eingang im Zielsystem sichtbar; ein Rückstand über fünf Minuten löst einen Alarm aus." Darin stecken drei Dinge, die jede spätere Diskussion entschärfen: ein Perzentil statt eines Durchschnitts, eine konkrete Obergrenze und eine definierte Reaktion bei Überschreitung. Ergänzen Sie eine Aussage zur Vollständigkeit — darf ein Ereignis verloren gehen oder nicht — und die Architekturentscheidung fällt fast von selbst.