Von Andrew Tan
Der Unterschied zwischen nahezu-Echtzeit und tatsächlich-Echtzeit und warum die Lücke mehr kostet, als Sie denken
Die 4,7 Millionen Euro Verzögerung
Ein großer europäischer Einzelhändler verlor am Black Friday 2024 4,7 Millionen Euro. Nicht, weil ihre Website abgestürzt ist. Nicht, weil sie keine Lagerbestände mehr hatten. Weil ihr "Echtzeit"-Inventarsystem vier Stunden hinterherhinkte.
340.000 Kunden bestellten Artikel, die bereits ausverkauft waren. Das System zeigte Verfügbarkeit an. Das Lager hatte keine. Als die Diskrepanz auffiel, war der Schaden bereits angerichtet. Rückerstattungen wurden ausgestellt. Der Kundenservice war überlastet. Der Markenruf war angeschlagen. Die Nachanalyse ergab etwas Peinliches: Die Pipeline war nie für Echtzeit konzipiert. Sie war für "nahezu-Echtzeit" konzipiert, eine Unterscheidung, die in Architekturüberprüfungen technisch klang und sich in der Produktion als katastrophal herausstellte.
Ich habe Versionen dieser Geschichte dutzende Male gehört. Die Lücke zwischen dem, was "Echtzeit" verspricht, und dem, was die meisten Systeme liefern, ist größer, als die meisten Teams realisieren. Und sie wird größer, nicht kleiner, da die Kundenerwartungen steigen.
Wie ein Formel-1-Boxenstopp erfordert die Echtzeit-Datenverarbeitung Präzision, Koordination und die richtige Infrastruktur.
Was "Echtzeit" tatsächlich bedeutet (und nicht)
Die Branche hat diese Gewässer getrübt. Drei Kategorien werden unter demselben Label vermischt.
Batch bedeutet Stunden oder Tage zwischen Updates. Ihr nächtlicher ETL-Job. Ihr wöchentlicher Bericht. Klare Grenzen, vorhersehbare Zeitfenster, gut verstandene Fehlermodi.
Nahezu-Echtzeit bedeutet Minuten zwischen Updates. Das System überprüft alle fünf, fünfzehn, dreißig Minuten. Die meisten "Echtzeit-Dashboards" fallen hier hinein. Gut für viele Anwendungsfälle. Nicht gut für die, die am meisten zählen.
Echtzeit bedeutet Sekunden oder Sub-Sekunden. Das Ereignis tritt ein. Das System weiß es. Die nachgelagerte Aktion wird sofort ausgelöst.
Der Einzelhändler hatte kein Echtzeitproblem. Sie hatten ein nahezu-Echtzeit-System, das als Echtzeit vermarktet wurde, und niemand stellte den Unterschied in Frage, bis es sie vier Millionen Euro kostete.
Drei Kräfte, die den Wandel antreiben
Der Amazon-Effekt. Kunden erwarten alles sofort. Nicht, weil sie die technischen Anforderungen analysiert haben. Weil sie darauf trainiert wurden, es zu erwarten. Eine Shopify-Studie aus dem Jahr 2022 mit 12.000 Verbrauchern ergab, dass 73 % Echtzeit-Updates bei Checkout, Inventar und Versand erwarten. Nicht "innerhalb einer Stunde". Echtzeit.
Betriebsfenster schrumpfen. Betrugserkennung nach der Transaktion ist keine Erkennung. Es ist eine Benachrichtigung. Das Geld ist bereits weg. Fertigungslinien, die auf Batch-Qualitätsberichte warten, produzieren stundenlang fehlerhafte Einheiten, bevor jemand es bemerkt. Die Kosten der Verzögerung summieren sich schneller, als die meisten Tabellenkalkulationen erfassen können.
Wettbewerbsdruck. Wenn Ihr Konkurrent die Preise alle dreißig Sekunden aktualisiert und Sie alle sechs Stunden, konkurrieren Sie nicht. Sie beobachten. Das ist nicht theoretisch. E-Commerce-Plattformen, Reiseaggregatoren, Finanzdienstleistungen. Die Unternehmen, die in diesen Bereichen gewinnen, haben Echtzeit-Dateninfrastruktur zu einer strategischen Priorität gemacht, nicht zu einem technischen Nice-to-have.
Geschwindigkeit ohne Kontrolle ist gefährlich. Echtzeit-Systeme müssen Geschwindigkeit handhaben, während sie Genauigkeit und Zuverlässigkeit aufrechterhalten.
Die verborgene Komplexität
Der Übergang von Batch zu Streaming ist schwieriger, als es aussieht. Die Oberfläche scheint einfach: anstatt zu warten, sofort reagieren. Darunter ändert sich alles.
Zustandsverwaltung. Batch-Jobs verarbeiten begrenzte Datensätze. Sie kennen die Eingabegröße, wenn Sie starten. Streaming verarbeitet unbegrenzte Streams. Sie müssen Fenster verfolgen, spät eintreffende Daten handhaben, den Zustand über Ereignisse hinweg verwalten, die möglicherweise in der falschen Reihenfolge eintreffen.
Genau-einmal-Verarbeitung. Einen Batch-Job versehentlich zweimal ausführen? Sie erhalten doppelte Ausgaben, beheben es, machen weiter. Eine Streaming-Pipeline zweimal ausführen? Sie berechnen Kunden doppelt, zählen Inventar doppelt, benachrichtigen Systeme doppelt. Die Semantik spielt eine Rolle, die sie zuvor nicht hatte.
Rückstau. Was passiert, wenn Ihre Quelle schneller produziert, als Ihr Senke konsumieren kann? In Batch zeigt sich das als langsamer Job. In Streaming zeigt es sich als verlorene Nachrichten, kaskadierende Ausfälle oder Systeme, die einfach nicht mehr reagieren.
Dies sind keine seltenen Randfälle. Sie sind Alltag. Teams, die diese Komplexität unterschätzen, enden mit Pipelines, die in Demos funktionieren und in der Produktion versagen.
Wie gutes Aussehen aussieht
Gut konzipierte Echtzeit-Systeme teilen gemeinsame Merkmale.
Resilienz von Haus aus. Nicht nachträglich angebaut. Das System erwartet, dass Komponenten ausfallen, und funktioniert weiter. Schutzschalter. Anmutige Degradation. Begrenzte Warteschlangen, die Last abwerfen, anstatt abzustürzen.
Beobachtbar. Sie müssen sehen, was in einer Pipeline passiert, die Tausende von Ereignissen pro Sekunde verarbeitet. Metriken, die zählen. Tracing, das Ereignisse durch das System verfolgt. Alarme, die bei Symptomen auslösen, nicht nur bei Komponentenausfällen.
Wachstumsbereit. Das System, das zehntausend Ereignisse pro Minute verarbeitet, sollte zehn Millionen ohne Neuschreibung verarbeiten. Horizontale Skalierung. Partitionsbewusstes Design. Keine einzelnen Engpässe.
Zugänglich. Echtzeit-Datenintegration sollte keinen Doktortitel in verteilten Systemen erfordern. Die Werkzeuge existieren. Die Dokumentation ist klar. Die Konzepte sind erlernbar. Teams sollten in Tagen produktiv sein, nicht in Quartalen.
Dieser letzte Punkt ist wichtiger als die anderen. Die Teams, die mit Echtzeit-Infrastruktur erfolgreich sind, sind nicht die mit der ausgeklügeltsten Technologie. Es sind die, die es ihren bestehenden Teams zugänglich genug gemacht haben, um es zu betreiben.
Die Zugänglichkeitslücke
Es bildet sich ein Zwei-Klassen-Markt. Erste Klasse: Unternehmen mit dedizierten Streaming-Teams, Kafka-Expertise, Infrastruktur-Ingenieuren, die Partitionsausgleich und genau-einmal-Semantik verstehen. Zweite Klasse: alle anderen, die bei Batch hängen bleiben, weil Echtzeit zu komplex erscheint, um es zu versuchen.
Das ist rückwärts. Echtzeit-Datenintegration sollte so zugänglich sein wie Batch-Verarbeitung. Gleiches Team. Gleicher Kenntnisstand. Gleiche Zeit bis zur Produktion. Die Technologie ist da. Was fehlt, ist die Verpackung. Werkzeuge, die die Komplexität handhaben, damit die Teams es nicht müssen.
Bei layline.io bauen wir für die zweite Klasse. Einheitliche Workflows, die sowohl Batch als auch Streaming mit denselben Schnittstellen handhaben. Eingebaute Resilienz und Beobachtbarkeit. Skalierung, die automatisch erfolgt. Das Ziel ist nicht, Streaming einfach zu machen. Es ist komplex, und etwas anderes zu behaupten, hilft niemandem. Das Ziel ist, es zugänglich zu machen.
Denn die Einzelhändler, Hersteller und Finanzdienstleistungsunternehmen, die Echtzeit-Daten benötigen, haben bereits kluge Teams. Sie brauchen keine anderen Leute. Sie brauchen bessere Werkzeuge.
Andrew Tan ist ein Serienunternehmer und Gründer von layline.io, das Unternehmensdatenverarbeitungsinfrastruktur entwickelt, die sowohl Batch- als auch Echtzeit-Workloads in großem Maßstab verarbeitet.