Vertikal und horizontal skalieren

Wenn ein System langsamer wird, weil mehr Menschen es nutzen, gibt es zwei grundsätzliche Wege: einen größeren Server nehmen oder mehr Server nehmen. Diese beiden Wege heißen vertikale und horizontale Skalierung. Beide haben ihre Berechtigung, und die Kunst liegt darin, zu wissen, wann welcher sinnvoll ist – und vor allem, wo der eigentliche Engpass liegt. Denn mehr Server helfen nichts, wenn die Datenbank der Flaschenhals ist.

1. Zwei Wege

Vertikale Skalierung ist die einfachste Lösung. Die Anwendung bleibt unverändert, man wählt nur einen größeren Server. Moderne Server bieten Hunderte Prozessorkerne und Terabytes an Arbeitsspeicher, sodass dieser Weg erstaunlich weit trägt – besonders für Datenbanken, die sich schwer verteilen lassen. Die Grenzen: Irgendwann gibt es keinen größeren Server mehr, sehr große Server sind überproportional teuer, und ein einzelner Server bleibt ein einzelner Ausfallpunkt.

Horizontale Skalierung ist flexibler. Statt einen riesigen Server zu betreiben, verteilt man die Last auf viele kleine, die sich bei Bedarf hinzufügen oder entfernen lassen. Fällt einer aus, übernehmen die anderen. Der Preis dafür ist Komplexität: Man braucht einen Load Balancer, die Anwendung muss so gebaut sein, dass jede Instanz jede Anfrage bearbeiten kann, und geteilter Zustand muss außerhalb der Anwendung liegen.

2. Zustandslosigkeit

Die wichtigste Voraussetzung für horizontale Skalierung ist, dass die Anwendungsserver zustandslos sind. Das bedeutet: Kein Server hält Daten im Arbeitsspeicher oder auf der Festplatte, die für spätere Anfragen gebraucht werden. Sitzungsdaten liegen in einem gemeinsamen Speicher wie Redis oder stecken als signiertes Token im Client, hochgeladene Dateien liegen im Objektspeicher, Zwischenergebnisse in der Datenbank oder im Cache. Dann ist es egal, welcher Server eine Anfrage bearbeitet, und Server können jederzeit hinzukommen oder wegfallen. Rechnen Sie aus, wie viele Instanzen eine API braucht:

Die Kapazität pro Instanz sollte gemessen, nicht geschätzt werden. Ein Lasttest mit Werkzeugen wie k6 oder Locust zeigt, wie viele Anfragen eine Instanz verarbeiten kann, bevor die Antwortzeiten steigen. Wichtig ist dabei, realistische Anfragen zu verwenden: Eine Startseite aus dem Cache ist um Größenordnungen günstiger als eine Suche mit komplexer Datenbankabfrage.

3. Den Engpass finden

Bevor man skaliert, muss man wissen, was eigentlich knapp ist. Ein System ist immer nur so schnell wie sein langsamster Teil. Wenn die Anwendungsserver zu 20 Prozent ausgelastet sind, die Datenbank aber zu 95 Prozent, helfen zehn zusätzliche Anwendungsserver nichts – sie schicken nur noch mehr Anfragen an die überlastete Datenbank. Die Engpässe liegen typischerweise an wenigen Stellen: bei der Datenbank, bei externen Diensten, bei der Netzwerkbandbreite, bei rechenintensiven Aufgaben oder bei Sperren und Verbindungspools.

4. Automatische Skalierung

Cloud-Plattformen und Container-Orchestrierung bieten automatische Skalierung: Steigt die Auslastung über einen Schwellenwert, werden neue Instanzen gestartet, sinkt sie, werden Instanzen entfernt. Das spart Kosten in ruhigen Zeiten und fängt Spitzen ab. Einige Punkte sind dabei zu beachten. Neue Instanzen brauchen Zeit zum Starten, manchmal Minuten; für plötzliche Spitzen muss deshalb eine Reserve vorhanden sein. Die Messgröße sollte gut gewählt werden – Prozessorauslastung passt für rechenintensive Dienste, für wartende Dienste sind Anfragen pro Sekunde oder die Länge von Warteschlangen oft besser. Und es braucht Obergrenzen, damit ein Fehler oder ein Angriff nicht zu Hunderten Instanzen und einer riesigen Rechnung führt.

Für viele kleine und mittlere Anwendungen ist automatische Skalierung gar nicht nötig. Zwei oder drei feste Instanzen mit ausreichender Reserve decken die Last zuverlässig ab und sind einfacher zu betreiben. Automatische Skalierung lohnt sich vor allem bei stark schwankender Last, etwa bei einem Ticketverkauf, bei saisonalen Geschäften oder bei Lernplattformen mit Spitzen vor Prüfungen.

5. Eine typische Ausbaureihenfolge

Wie wachsen Systeme in der Praxis? Eine häufige Reihenfolge sieht so aus. Am Anfang laufen Anwendung und Datenbank auf einem Server. Der erste Schritt trennt beide auf eigene Server, damit sie sich nicht gegenseitig Ressourcen wegnehmen. Dann wird die Anwendung zustandslos gemacht und auf zwei Instanzen hinter einem Load Balancer verteilt, vor allem für Ausfallsicherheit. Statische Inhalte wandern ins CDN, häufige Leseanfragen in einen Cache. Die Datenbank wächst zunächst vertikal und bekommt ein Replikat. Langsame Aufgaben werden in Warteschlangen ausgelagert. Erst sehr viel später, wenn überhaupt, kommen Themen wie Sharding oder mehrere Regionen dazu.

Diese Reihenfolge ist kein Gesetz, aber ein guter Leitfaden. Jeder Schritt löst ein konkretes Problem und sollte erst gemacht werden, wenn dieses Problem tatsächlich auftritt oder absehbar ist. Die folgenden Lektionen dieses Moduls vertiefen die einzelnen Bausteine: Lastverteilung, Caching, Warteschlangen, Event Streaming, der richtige Umgang mit Zeitlimits und Wiederholungen und schließlich der Schutz vor Überlastung durch Rate Limiting.

6. Ein Beispiel

Eine Lernplattform mit 50.000 täglich aktiven Nutzern erwartet zum Semesterstart die dreifache Last. Die Messung zeigt: Die API-Instanzen sind im Peak zu 40 Prozent ausgelastet, die Datenbank zu 70 Prozent, und die Hälfte der Datenbanklast entfällt auf drei Abfragen für Kursübersichten, die sich selten ändern. Statt die Zahl der API-Instanzen zu verdreifachen, werden die drei Abfragen für eine Minute gecacht, was die Datenbanklast halbiert, und eine dritte API-Instanz wird als Reserve ergänzt. Der Semesterstart läuft ohne Probleme, und die zusätzlichen Kosten sind minimal. Das Beispiel zeigt: Wer misst, bevor er skaliert, braucht oft viel weniger zusätzliche Kapazität als gedacht.

7. Checkliste für den Entwurf

Wer in einem Entwurf oder Vorstellungsgespräch über Skalierung spricht, sollte einige Fragen systematisch beantworten. Wie hoch ist die erwartete Last im Durchschnitt und in der Spitze, und wie schnell wächst sie? Welche Komponente wird zuerst zum Engpass, und woher weiß man das? Sind die Anwendungsserver zustandslos, und wo liegen Sitzungen, Dateien und Zwischenergebnisse? Wie viele Instanzen braucht man für die Spitzenlast, und wie viele zusätzlich, damit der Ausfall einer Instanz verkraftet wird? Soll automatisch skaliert werden, und falls ja, nach welcher Messgröße, mit welcher Reserve und mit welcher Obergrenze? Und schließlich: Was kostet jede Ausbaustufe, und lohnt sich die zusätzliche Komplexität im Verhältnis zum Nutzen?

Diese Fragen klingen selbstverständlich, werden aber in der Praxis oft übersprungen. Viele Teams beginnen mit einer aufwendigen Architektur aus zahlreichen Diensten, obwohl ein einzelner, gut gewarteter Server die Last für Jahre tragen würde. Andere unterschätzen, wie schnell eine einzelne Datenbank an ihre Grenzen kommt, wenn plötzlich ein Artikel über das Produkt viral geht. Eine ehrliche Kapazitätsplanung mit gemessenen Zahlen, einer klaren Reserve und einem vorbereiteten nächsten Schritt schützt vor beiden Fehlern. Sie sollte regelmäßig, etwa jedes Quartal, mit den aktuellen Messwerten überprüft werden, damit das Team nicht vom eigenen Wachstum überrascht wird und rechtzeitig reagieren kann.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.