Lastspitzen im Griff: Skalierung für Echtzeit-Games & E-Commerce

Ich habe an Football Empire mitgebaut, einem Fußball-Manager, bei dem zum Release Zehntausende gleichzeitig online gingen. Und ich habe Shops betreut, deren Jahresumsatz sich an wenigen Stunden entscheidet. Technisch ist das dasselbe Problem: eine kurze, brutale Lastspitze, bei der jede Sekunde Wartezeit direkt Geld oder Spieler kostet.

Der Durchschnitt lügt

Wer seine Kapazität am durchschnittlichen Traffic auslegt, plant am eigentlichen Ereignis vorbei. Relevant ist die Spitze – und die ist bei Games und Sales nicht doppelt, sondern oft fünfzig- bis hundertmal so hoch wie der Normalbetrieb. Der Punkt, an dem ein System bricht, liegt fast immer an einer Stelle, an die vorher niemand gedacht hat: eine Datenbank-Verbindung, ein Cache, ein einzelner synchroner Aufruf.

Was in der Praxis trägt

• Lasttests unter Realbedingungen – die Spitze simulieren, bevor sie echt ist. Was ungetestet ist, skaliert nicht.
• Entkopplung über Queues – Schreiblast abfedern, statt die Datenbank direkt gegen die Wand fahren zu lassen.
• Aggressives Caching – für das, was viele gleichzeitig lesen, aber selten ändert.
• Graceful Degradation – lieber eine Funktion abschalten als die ganze Seite verlieren.

Ein System, das unter Last eine Nebenfunktion opfert und online bleibt, ist jedem überlegen, das alles kann – bis es nichts mehr kann.

Die Ruhe kommt aus der Vorbereitung

Der eigentliche Unterschied zwischen einem gelungenen Release und einem Feuerwehreinsatz liegt nicht im Moment der Spitze, sondern in den Wochen davor: im ehrlichen Lasttest, im Durchspielen der Fehlerfälle, im Bereithalten der Notschalter. Echtzeit und Stabilität unter Druck sind keine Glückssache – sie sind das Ergebnis von Vorbereitung, die man vorher gemacht hat, obwohl noch alles ruhig war.