Webanwendung skalieren: Von 100 auf 100.000 Nutzer

Kurz gefasst: Eine Webanwendung zu skalieren heißt, Engpässe in der Reihenfolge zu beheben, in der sie tatsächlich auftreten. Meist ist das zuerst die Datenbank: fehlende Indizes, ineffiziente Abfragen, zu viele Verbindungen. Danach folgen Caching, ein CDN für statische Inhalte, mehrere Instanzen der Anwendung hinter einem Load Balancer und Hintergrundjobs für langsame Aufgaben. Ein gut gebauter Monolith auf einer soliden Datenbank trägt viele Anwendungen weit über hunderttausend Nutzer, ohne dass Microservices nötig werden.

Zuerst messen, dann skalieren

Skalierung ohne Messung ist Raten. Bevor Sie Infrastruktur hinzufügen, brauchen Sie Antworten auf einfache Fragen: Welche Anfragen sind langsam? Wo verbringt der Server seine Zeit? Wie ausgelastet sind CPU, Arbeitsspeicher und Datenbank? Application Performance Monitoring, strukturierte Logs und Metriken zeigen das. Wie Sie das aufsetzen, beschreibt unser Beitrag zu Monitoring und Observability.

Wichtig ist auch die Frage, was „Nutzer“ für Ihre Anwendung bedeutet. Hunderttausend registrierte Konten, die sich einmal im Monat anmelden, sind eine andere Last als einige tausend gleichzeitige Nutzer, die ständig Daten schreiben. Planen Sie nach gleichzeitiger Last und Anfragen pro Sekunde, nicht nach Kontozahlen.

Die typischen Stufen der Skalierung

Ein Server, eine Datenbank

Am Anfang reicht für die meisten Anwendungen ein Anwendungsserver mit einer verwalteten Datenbank, etwa PostgreSQL bei einem Cloud-Anbieter. Das ist einfach zu betreiben und günstig. Wichtiger als jede Infrastruktur ist in dieser Phase ein sauberes Datenmodell. Welche Datenbank sich dafür eignet, vergleichen wir im Leitfaden zur Datenbankauswahl.

Die Datenbank entlasten

Der erste echte Engpass liegt fast immer in der Datenbank. Typische Ursachen sind fehlende Indizes, N+1-Abfragen aus dem ORM und Abfragen, die mehr Daten laden als nötig. Mit EXPLAIN ANALYZE in PostgreSQL finden Sie langsame Abfragen schnell. Ein Connection Pooler wie PgBouncer verhindert, dass viele Anwendungsinstanzen die Datenbank mit Verbindungen überlasten. Wächst die Last weiter, übernehmen Lese-Replikate einen Teil der Leseanfragen.

Caching und CDN

Statische Dateien wie Bilder, JavaScript und CSS gehören auf ein CDN, das sie nah am Nutzer ausliefert. Für dynamische Daten, die sich selten ändern, lohnt ein Cache wie Redis oder Valkey. Seiten, die für alle Besucher gleich aussehen, lassen sich vorab rendern oder für kurze Zeit zwischenspeichern. Jeder Cache bringt aber die Frage mit, wann er ungültig wird. Fangen Sie mit wenigen, klar abgegrenzten Stellen an.

Horizontale Skalierung der Anwendung

Wenn ein Server nicht mehr reicht, starten Sie mehrere Instanzen hinter einem Load Balancer. Voraussetzung ist, dass die Anwendung zustandslos ist: Sitzungen liegen in der Datenbank oder in Redis, hochgeladene Dateien in einem Objektspeicher, nicht auf der lokalen Festplatte. Container und Plattformen mit automatischer Skalierung machen diesen Schritt vergleichsweise einfach. Eine CI/CD-Pipeline sorgt dafür, dass alle Instanzen denselben Stand haben. Wie sie aufgebaut wird, zeigt unser Praxisleitfaden für CI/CD-Pipelines.

Hintergrundjobs und Warteschlangen

E-Mails versenden, PDFs erzeugen, Bilder verarbeiten, Daten importieren: Solche Aufgaben gehören nicht in die Anfrage des Nutzers. Eine Warteschlange mit eigenen Worker-Prozessen nimmt sie entgegen und arbeitet sie im Hintergrund ab. Die Anwendung bleibt reaktionsschnell, und Lastspitzen werden abgefedert.

Wann Microservices sinnvoll werden

Microservices lösen vor allem organisatorische Probleme: Mehrere Teams sollen unabhängig voneinander entwickeln und ausliefern können. Für ein kleines Team bringen sie meist mehr Aufwand als Nutzen, weil Netzwerkkommunikation, verteilte Fehlersuche und Datenkonsistenz hinzukommen. Ein modular aufgebauter Monolith lässt sich später gezielt aufteilen, wenn ein Teil wirklich eigene Anforderungen hat. Die Abwägung im Detail finden Sie in unserem Artikel Microservices oder Monolith.

Typische Fehler

Der häufigste Fehler ist, zu früh für eine Last zu bauen, die noch nicht existiert. Komplexe Infrastruktur kostet Geld und Entwicklungszeit, die im Produkt fehlt. Ebenso gefährlich ist das Gegenteil: Niemand beobachtet die Kennzahlen, bis die Anwendung bei der ersten Marketingkampagne zusammenbricht. Lasttests vor absehbaren Spitzen und Alarme bei steigenden Antwortzeiten verhindern solche Überraschungen.

Häufige Fragen (FAQ)

Ab wann muss ich mich um Skalierung kümmern?

Sobald Ihre Messungen zeigen, dass Antwortzeiten steigen oder Ressourcen knapp werden. Vorher genügen ein sauberes Datenmodell, Monitoring und eine Architektur, die später horizontale Skalierung erlaubt. Mehr Vorleistung lohnt sich selten.

Brauche ich Kubernetes für eine skalierbare Anwendung?

Nicht zwingend. Viele Anwendungen laufen gut auf verwalteten Container-Plattformen oder PaaS-Angeboten, die automatisch skalieren. Kubernetes lohnt sich eher, wenn Sie viele Dienste betreiben und ein Team haben, das die Plattform pflegen kann.

Was kostet Skalierung in der Cloud?

Das hängt stark von Architektur und Nutzungsmuster ab. Die größten Kostentreiber sind oft überdimensionierte Server, unnötig große Datenbanken und Datenübertragung. Regelmäßige Auswertung der Kosten und automatische Skalierung nach Bedarf halten die Rechnung im Rahmen.

Kann ich meine Anwendung in Deutschland hosten und trotzdem skalieren?

Ja. Deutsche und europäische Cloud-Anbieter bieten verwaltete Datenbanken, Container und Load Balancer, und die großen Anbieter haben Rechenzentren in Deutschland. Für die meisten Anwendungen ist der Serverstandort kein Hindernis für Wachstum.

Fazit

Skalierung ist eine Abfolge kleiner, gemessener Schritte: Datenbank optimieren, cachen, horizontal skalieren, Arbeit in den Hintergrund verlagern. Wer jeden Schritt erst geht, wenn die Daten ihn verlangen, wächst mit einer Infrastruktur, die er versteht und bezahlen kann. Wenn Sie Ihre Webanwendung auf Wachstum vorbereiten möchten, sprechen Sie mit uns über Webentwicklung und Architektur.