Echtzeit-Systeme unter Last: So skaliert die „Bestellung stornieren“-Funktion auf 100.000 Anfragen pro Sekunde

Ein Klick auf „Bestellung stornieren“ sollte in Sekundenbruchteilen möglich sein – doch was passiert, wenn 60.000 Nutzer gleichzeitig auf die Schaltfläche zugreifen? Der Schlüssel liegt nicht in mehr Servern, sondern in schlauer Architektur.

Die Herausforderung: Zwei Nutzerverhalten, eine Millisekunde

Jede Lieferung durchläuft zwei typische Nutzerphasen, die die Systemlast dramatisch erhöhen:

• Map-Nutzer beobachten den Lieferstatus und aktualisieren alle 30 Sekunden die Karte. Bei einer Lieferzeit von 15 Minuten summiert sich das auf bis zu 30 Abfragen pro Nutzer.

• Chat-Nutzer öffnen den Support und erwarten Echtzeit-Updates. Ändert sich der Fahrerstatus während des Chattens, muss die Stornierungsoption sofort verschwinden – ohne dass die Seite neu geladen wird.

Kombiniert resultieren diese Verhaltensmuster in einem Datenstrom von über 100.000 Anfragen pro Sekunde (RPS), der die Backend-Systeme belastet. Der kritische Moment: Die Stornierungsoption darf weder zu früh noch zu spät angezeigt werden.

Die drei Lösungsansätze – und warum zwei scheitern

❌ Lösung 1: Die Kettenreaktion (Direkte API-Abfragen)

Die naheliegendste Methode ist eine direkte Kommunikation zwischen Nutzer-App und Fulfillment-System. Jede Kartenerneuerung löst eine Abfrage aus: „Darf der Nutzer jetzt stornieren?“

Doch der Ansatz scheitert an der Realität: Das Fulfillment-System ist bereits mit der Verarbeitung von GPS-Daten und Fahrerzuweisungen ausgelastet. 100.000 Leseanfragen pro Sekunde überlasten die Datenbank, führen zu Deadlocks und bringen das gesamte System zum Stillstand.

❌ Lösung 2: Der „Sind wir da?“-Warteschleifen-Mechanismus (Hintergrundprozesse)

Um das Fulfillment-System zu entlasten, setzt ein zweiter Ansatz auf Hintergrundprozesse, die regelmäßig den Status aller aktiven Bestellungen abfragen und in einem Cache speichern.

Probleme:

• Verschwendung von Ressourcen: Über 95 % der Abfragen liefern keine Änderungen – trotzdem wird jede Bestellung alle zwei Sekunden geprüft.
• Zeitfenster für Missbrauch: Eine Verzögerung von zwei Sekunden ermöglicht trickreichen Nutzern, die Stornierungstaste genau in der kritischen Phase zu nutzen.
• Hoher Energieverbrauch: Kontinuierliches Polling belastet Server und Netzwerk unnötig.

✅ Lösung 3: Ereignisgesteuerte Logik (Die Skalierungsstrategie der Tech-Giganten)

Der Durchbruch gelingt durch den Wechsel von zeitbasierter zu ereignisbasierter Steuerung. Zwei Prinzipien stehen im Mittelpunkt:

1. Zeit nicht aktiv überwachen, sondern vorab berechnen
2. Echtwelt-Änderungen als Auslöser nutzen

Die geniale Architektur: Mathematik und Ereignisse vereint

Schritt A: Die Zeit berechnen, bevor sie abläuft

Sobald eine Bestellung aufgegeben wird, berechnet das System den exakten Zeitpunkt, ab dem eine Stornierung erlaubt ist:

Erlaubt ab: 8:00 PM + 10 Minuten = 8:10 PM

Diese Information wird in einem Redis-Cache gespeichert – einem extrem schnellen In-Memory-Datenspeicher. Die Nutzer-App fragt bei jeder Kartenerneuerung nicht das Fulfillment-System ab, sondern führt eine submillisekunden-schnelle Abfrage durch:

const zeit_abgelaufen = aktuelle_zeit > erlaubte_stornierung_zeit;
const fahrer_angekommen = (status === "ANGKOMMEN_VOR_DER_TÜR");

if (zeit_abgelaufen && !fahrer_angekommen) {
  zeige_stornierungstaste = true;
} else {
  zeige_stornierungstaste = false;
}

Keine Datenbankabfragen, keine Hintergrundprozesse – nur eine einfache mathematische Prüfung. Die Zeit selbst übernimmt die Arbeit.

Schritt B: Echtzeit-Updates per Push-Architektur

Für die Chat-Nutzer, die eine sofortige Aktualisierung benötigen, setzt das System auf Ereignisweiterleitung:

1. Der Fahrer trifft ein: Das Fulfillment-System sendet eine Benachrichtigung an einen Message-Broker (z. B. Kafka) mit dem Inhalt: „Bestellung 456: Fahrer angekommen“.

1. Das Eligibility-System hört zu: Ein dedizierter Dienst empfängt die Nachricht und aktualisiert den Redis-Cache sofort mit dem neuen Status Fahrer_Angekommen = true.

1. Die Chat-App erhält das Update in Echtzeit: Über eine WebSocket-Verbindung wird die Nachricht direkt an die aktive Nutzer-Sitzung gesendet – die Stornierungstaste verschwindet innerhalb von Millisekunden.

Die Lehre aus 100.000 Anfragen pro Sekunde

Skalierbarkeit ist kein Hardware-Problem, sondern ein Design-Problem. Die erfolgreichsten Systeme folgen drei Grundsätzen:

• Vermeide aktive Überwachung: Nutze vorab berechnete Werte (z. B. Zeitstempel) statt kontinuierliches Polling.

• Lass die Realität für dich arbeiten: Ereignisse wie „Fahrer angekommen“ sind zuverlässigere Trigger als selbstgebaute Zeitmessungen.

• Dezentrale Logik: Verteile die Entscheidungshoheit auf spezialisierte Dienste (Eligibility, Fulfillment) und nutze Caching für Geschwindigkeit.

In einer Welt, in der Nutzer sofortige Reaktionen erwarten, entscheidet nicht die Rechenleistung über den Erfolg – sondern die Fähigkeit, intelligent faul zu sein.