System Design Angst? So meistern Sie Back-of-the-Envelope Schätzungen
Die System Design Interviews können entmutigend wirken. Sie sitzen da, der Interviewer fragt: "Wie viele Server brauchen wir für 10 Millionen Nutzer?" Panik? Nicht nötig. Die Fähigkeit, schnell und rational Schätzungen vorzunehmen – die sogenannte Back-of-the-Envelope (BoE) Schätzung – ist keine Magie, sondern eine erlernbare Technik.
Sie zeigt dem Interviewer, dass Sie ein Gefühl für Skalierung und Kosten haben. Als Ihr "Candidate Protector" zeigen wir Ihnen die wichtigsten Tricks, um QPS und Storage blitzschnell zu berechnen, ohne einen Taschenrechner zu benötigen.
Warum BoE im System Design unverzichtbar ist
BoE-Schätzungen dienen nicht der exakten Genauigkeit, sondern der Überprüfung der Machbarkeit und der Größenordnung. Sie ermöglichen es Ihnen, schnell abzuschätzen, ob eine Lösung 10 Server oder 10.000 Server benötigt. Im Interview demonstrieren Sie damit kritisches Denken und ein tiefes Verständnis für technische Kompromisse.
Die Magischen Zahlen: Was Sie auswendig wissen müssen
Um schnell zu rechnen, müssen Sie die gängigen Potenzen von 10 und einige Schlüsselkonstanten im Kopf haben. Runden Sie immer großzügig! Im BoE-Kontext ist es besser, $10^5$ zu verwenden als 86.400 (Sekunden pro Tag).
| Einheit | Wert (Gerundet) |
|---|---|
| 1 Tausend (K) | $10^3$ |
| 1 Million (M) | $10^6$ |
| 1 Milliarde (B) | $10^9$ |
| Sekunden pro Tag | $\approx 10^5$ |
| Bytes in MB | $10^6$ |
| MB in GB | $10^3$ |
Der wichtigste Shortcut:
- $10^6$ Anfragen pro Tag $\approx$ 11.6 QPS.
- Merken Sie sich: 1 Million Requests/Tag sind ungefähr 10 QPS. Dies ist der Goldstandard für schnelle Abschätzungen.
QPS berechnen (Requests per Second)
Die Berechnung der QPS ist entscheidend, um die nötige Serverlast zu bestimmen. Gehen Sie in vier einfachen Schritten vor:
Schritt 1: Traffic und Nutzung definieren Wie viele Nutzer (User) gibt es? (Z.B. 100 Millionen registrierte Nutzer). Wie viele davon sind täglich aktiv (Daily Active Users, DAU)? (Nehmen wir an, 10%, also $10^7$ DAU).
Schritt 2: Requests pro DAU schätzen Wie oft interagiert der durchschnittliche Nutzer pro Tag mit der kritischen Funktion? (Z.B. 4 Leseanfragen und 1 Schreibanfrage pro DAU). Gesamtanfragen pro Tag: $10^7 \text{ DAU} \times 5 \text{ Requests/DAU} = 50 \text{ Millionen Requests pro Tag}$.
Schritt 3: QPS ableiten Wir nutzen unseren Shortcut: $1 \text{ Million Requests/Tag} \approx 10 \text{ QPS}$. 50 Millionen Requests/Tag $\approx 500 \text{ QPS}$.
Schritt 4: Peak Traffic berücksichtigen Die 500 QPS sind der Durchschnitt. Aber Nutzer verteilen sich nicht gleichmäßig über 24 Stunden. Schätzen Sie den Peak-Faktor (z.B. 3x). Peak QPS: $500 \text{ QPS} \times 3 = 1500 \text{ QPS}$.
Ergebnis: Das System muss 1500 Anfragen pro Sekunde im Spitzenbetrieb bewältigen können.
Storage berechnen: Wie viel Speicher brauchen wir?
Die Speicherabschätzung (Storage Estimation) folgt einer ähnlichen Logik, konzentriert sich jedoch auf kumulative Daten.
Schritt 1: Größe eines einzelnen Datensatzes definieren Wie groß ist ein einzelner Eintrag (z.B. ein Benutzerprofil oder ein Foto-Post)? (Z.B. 1 KB für Textdaten oder 500 KB für ein komprimiertes Bild).
Schritt 2: Gesamtzahl der Einträge über die Zeit schätzen Nehmen wir an, wir speichern Benutzerbeiträge (Posts). 10 Millionen DAU. Jeder macht 1 Post pro Woche. Posts pro Tag: $10^7 \text{ DAU} / 7 \approx 1.5 \text{ Millionen Posts/Tag}$. Speicher pro Tag (angenommen 1 KB pro Post): $1.5 \times 10^6 \text{ Posts} \times 1 \text{ KB/Post} = 1.5 \text{ GB/Tag}$.
Schritt 3: Gesamtspeicherbedarf berechnen Wie lange müssen die Daten gespeichert werden (z.B. 5 Jahre)? Gesamtspeicher: $1.5 \text{ GB/Tag} \times 365 \text{ Tage/Jahr} \times 5 \text{ Jahre} \approx 2737 \text{ GB}$.
Runden Sie auf: 3 TB (Terabyte) in fünf Jahren.
Pro-Tipp: Denken Sie immer an Replikation, Indizes und Overhead – verdoppeln oder verdreifachen Sie den Wert für eine realistischere Schätzung.
Fazit: Übung macht den Meister
BoE-Schätzungen sind das A und O im System Design Interview. Sie müssen keine Taschenrechner-Genauigkeit liefern, sondern Konsistenz und Argumentation. Zeigen Sie dem Interviewer Ihre Annahmen, schreiben Sie sie auf und arbeiten Sie logisch von der Anzahl der Nutzer zum Peak-Traffic.
Sie fühlen sich unsicher, wie Sie solche Zahlen im Interview präsentieren sollen? Unser [Interview War Room] von RolePilot hilft Ihnen, die Antworten zu strukturieren und überzeugend aufzutreten. Schauen Sie sich auch unseren ATS Reality Check an, um sicherzustellen, dass Ihr Lebenslauf die erste Hürde nimmt, bevor Sie überhaupt zum System Design Interview eingeladen werden.
FAQ zur Back-of-the-Envelope Schätzung
Q: Soll ich Runden oder exakt rechnen? A: Immer runden! $10^5$ statt 86.400 ist schneller und im BoE-Kontext völlig ausreichend. Ziel ist die Größenordnung (Order of Magnitude), nicht die Präzision.
Q: Was ist, wenn meine Annahmen falsch sind? A: Das ist in Ordnung. Der Interviewer bewertet, wie Sie Ihre Annahmen herleiten und ob Sie die Auswirkungen (z.B. Peak Traffic) berücksichtigen. Machen Sie Ihre Annahmen explizit und verhandelbar.
Q: Wie oft muss ich QPS und Storage üben? A: Üben Sie, die Schlüsselkonstanten (Seconds/Day, KB/MB/GB) zu internalisieren. Versuchen Sie, alltägliche Dinge abzuschätzen (z.B. wie viel Speicher braucht eine große E-Commerce-Plattform in 10 Jahren?).
CTA: Bereiten Sie sich optimal auf Ihr nächstes Tech-Interview vor. Nutzen Sie den [Interview War Room] von RolePilot, um Ihre System Design Skills zu perfektionieren und mit Zahlen zu glänzen.