Überschlagsrechnungen: Last und Speicher schätzen

Ob ein System für hundert oder hunderttausend Nutzer entworfen wird, macht einen großen Unterschied. Trotzdem wird diese Frage erstaunlich oft übersprungen. Man entscheidet sich für Microservices, eine verteilte Datenbank oder einen Nachrichtenbus, ohne zu wissen, ob die erwartete Last das überhaupt rechtfertigt. Überschlagsrechnungen – im Englischen „back-of-the-envelope calculations“ – beantworten diese Frage in wenigen Minuten. Sie liefern keine exakten Zahlen, sondern Größenordnungen. Aber Größenordnungen genügen, um ungeeignete Lösungen auszuschließen und die wirklichen Engpässe zu erkennen.

1. Die Grundrechnung

Die wichtigste Rechnung passt auf einen Bierdeckel. Eine Lernplattform mit 50.000 täglich aktiven Nutzern, die jeweils 30 Anfragen am Tag auslösen, erzeugt 1,5 Millionen Anfragen täglich. Geteilt durch 86.400 Sekunden sind das etwa 17 Anfragen pro Sekunde im Durchschnitt. Weil die meisten Menschen abends lernen, liegt die Spitze vielleicht beim Vierfachen, also bei etwa 70 Anfragen pro Sekunde. Das ist eine Last, die ein einzelner gut konfigurierter Server mit einer relationalen Datenbank problemlos bewältigt. Die Erkenntnis ist wertvoll: Für diese Plattform ist horizontale Skalierung vorerst kein Thema; wichtiger sind saubere Abfragen, Backups und Sicherheit.

Probieren Sie es selbst aus. Der Rechner nimmt eine durchschnittliche Antwortgröße von 20 Kilobyte für die Bandbreite an.

2. Größenordnungen, die man kennen sollte

Neben der Last helfen einige Richtwerte, um Architekturen schnell einzuschätzen. Die berühmte Liste „Latency Numbers Every Programmer Should Know“, ursprünglich von Jeff Dean bei Google zusammengestellt, zeigt, wie unterschiedlich schnell verschiedene Operationen sind. Die genauen Werte ändern sich mit der Hardware, die Verhältnisse bleiben erstaunlich stabil.

Aus diesen Zahlen folgen praktische Regeln. Ein Aufruf über das Netzwerk ist um Größenordnungen langsamer als ein Zugriff auf den Arbeitsspeicher – deshalb sind Caches so wirksam und deshalb ist es teuer, eine Anfrage durch zehn Microservices zu schicken. Eine Anfrage über einen Ozean kostet allein durch die Physik fast 100 Millisekunden – deshalb gibt es CDNs und mehrregionale Systeme. Und eine KI-Antwort dauert Sekunden – deshalb müssen KI-Funktionen fast immer asynchron oder als Stream gestaltet werden.

3. Speicher und Wachstum

Die zweite wichtige Rechnung betrifft den Speicher. Man schätzt, wie viele Datensätze pro Tag entstehen und wie groß sie sind, und rechnet auf ein oder fünf Jahre hoch. Ein Buchungssystem, das 2.000 Buchungen am Tag mit je zwei Kilobyte speichert, wächst um etwa vier Megabyte täglich, knapp 1,5 Gigabyte im Jahr – vernachlässigbar für jede moderne Datenbank. Eine Plattform, auf der Nutzer täglich 10.000 Audiodateien mit je zwei Megabyte hochladen, erzeugt dagegen 20 Gigabyte pro Tag und mehr als sieben Terabyte im Jahr. Solche Daten gehören nicht in die Datenbank, sondern in einen Objektspeicher, wie das Modul zur Datenhaltung zeigt.

4. Von der Zahl zur Entscheidung

Die Schätzungen sind kein Selbstzweck. Sie sollen Entscheidungen ermöglichen. Einige typische Schlussfolgerungen: Liegt die Spitzenlast unter einigen hundert Anfragen pro Sekunde, genügt meist eine einfache Architektur mit einer Anwendung und einer Datenbank. Überwiegen Lesezugriffe stark, etwa im Verhältnis 100 zu 1, lohnen sich Caches und Lesereplikate. Wachsen große Dateien schnell, gehören sie in einen Objektspeicher mit CDN. Dauern einzelne Vorgänge Sekunden, etwa KI-Anfragen oder Videoverarbeitung, gehören sie in eine Warteschlange. Und kosten einzelne Anfragen Geld, etwa bei externen KI-Diensten, muss man die Kosten pro Anfrage genauso schätzen wie die Last.

5. Annahmen transparent machen

Jede Schätzung beruht auf Annahmen: Wie viele Nutzer kommen? Wie oft nutzen sie die Anwendung? Wie groß sind die Daten? Diese Annahmen sollten ausdrücklich aufgeschrieben werden. Das hat zwei Vorteile. Erstens können andere sie prüfen und korrigieren – vielleicht weiß der Vertrieb, dass zum Schulstart zehnmal so viele Nutzer kommen. Zweitens lässt sich später nachvollziehen, warum eine Entscheidung getroffen wurde, und prüfen, ob die Annahmen noch stimmen. Sobald ein System läuft, ersetzen echte Messwerte aus dem Monitoring die Schätzungen, und die Architektur kann gezielt dort ausgebaut werden, wo die tatsächlichen Engpässe liegen.

In Vorstellungsgesprächen gehören Überschlagsrechnungen zum Standard. Dort wird nicht erwartet, dass Sie exakte Werte kennen, sondern dass Sie strukturiert und nachvollziehbar rechnen, sinnvolle Annahmen treffen und daraus Schlüsse ziehen. Runden ist ausdrücklich erlaubt: 86.400 Sekunden werden zu 100.000, 1,5 Millionen Anfragen am Tag zu etwa 20 pro Sekunde. Entscheidend ist die Größenordnung, nicht die dritte Nachkommastelle. Wer diese Rechnungen einige Male geübt hat, macht sie im Kopf – und erkennt überdimensionierte Architekturen sofort.

6. Kosten mitdenken

Neben Last und Speicher gehört eine dritte Schätzung dazu, die oft vergessen wird: die Kosten. Viele Kosten skalieren direkt mit der Nutzung, etwa Speicher in der Cloud, ausgehender Datenverkehr, externe Dienste oder Aufrufe von KI-Modellen. Eine Rechnung pro Nutzer und Monat macht sichtbar, ob ein Geschäftsmodell trägt. Wenn eine KI-Funktion pro Aufruf einen Cent kostet und aktive Nutzer sie dreißigmal im Monat verwenden, entstehen dreißig Cent pro Nutzer und Monat – bei einem Abopreis von fünf Euro vertretbar, bei einem kostenlosen Angebot mit hunderttausend Nutzern ein ernstes Problem.

Solche Rechnungen führen oft zu Architekturentscheidungen: Antworten werden zwischengespeichert, einfache Aufgaben gehen an günstigere Modelle, teure Verarbeitung läuft gesammelt im Hintergrund. Das Modul zu Zuverlässigkeit und Betrieb vertieft die Kosten im Systementwurf, das Modul zu KI-Systemen die besonderen Kosten von Sprachmodellen. Für den Anfang genügt es, bei jeder Schätzung auch die Frage zu stellen: Was kostet uns das pro Nutzer und Monat?

Ein Tipp zum Üben: Nehmen Sie sich bekannte Anwendungen vor – eine Essensbestell-App, einen Streamingdienst, eine Vereinswebsite – und schätzen Sie deren Last, Speicherbedarf und Kosten grob ab. Vergleichen Sie Ihre Ergebnisse, wo möglich, mit veröffentlichten Zahlen. Nach einigen solchen Übungen entwickeln Sie ein Gefühl für Größenordnungen, das bei jeder Architekturentscheidung hilft und vor teuren Überdimensionierungen schützt. Halten Sie Ihre Rechnungen dabei immer schriftlich fest, mit allen Annahmen, damit andere sie nachvollziehen, prüfen und ergänzen können. Eine sauber dokumentierte Schätzung ist oft das überzeugendste Argument in jeder Architekturdiskussion. Sie ersetzt Meinungen durch nachvollziehbare Zahlen und schafft damit eine gemeinsame Grundlage für alle Beteiligten, vom Entwickler über den Betrieb bis zur Geschäftsführung.

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