Das Framework in fünf Phasen (getaktet auf 45 Minuten)
- Anforderungen – 5 Minuten. Trenne funktionale Anforderungen („URL kürzen, weiterleiten, eigene Aliase?“) von nicht funktionalen (Skalierung, Latenzziele, Verfügbarkeit vs. Konsistenz, Dauerhaftigkeit). Frag nach Zahlen: Nutzer, Lese- vs. Schreibzugriffe, Datenmenge. Dann sprich deinen Rahmen laut aus: „Ich entwerfe für 100 Mio. DAU, leselastig im Verhältnis 100:1, Weiterleitungen unter 100 ms, und Analytics lasse ich weg, sofern keine Zeit bleibt.“ Den Rahmen laut abzustecken ist der Zug mit dem stärksten Signal in der ganzen Runde.
- Schätzung – 5 Minuten. QPS, Speicher und Bandbreite als Überschlagsrechnung. Auf Zehnerpotenzen runden, Annahmen nennen, auf Plausibilität prüfen („500 Mio. neue URLs pro Monat ≈ 200 Schreibzugriffe pro Sekunde, das ist überschaubar. Lesezugriffe bei 100:1 ≈ 20.000 pro Sekunde, das bestimmt das Design“). Es geht nicht um Genauigkeit. Es geht darum zu zeigen, dass Zahlen deine Architekturentscheidungen leiten.
- High-Level-Design – 10 Minuten. Kästen und Pfeile für den Happy Path: Clients, Load Balancer, zustandslose App-Schicht, Datenspeicher, Cache, Queue. Geh einen Request laut von Anfang bis Ende durch. Halt es langweilig: Originalität ist hier Risiko ohne Gewinn.
- Deep Dives – 20 Minuten. Der Interviewer sucht sich eine Komponente aus („Wie genau vermeidet die ID-Generierung Kollisionen?“, „Was passiert, wenn ein Cache-Knoten ausfällt?“). Hier trennen sich die Levels. Werde konkret: Datenmodell, Wahl des Partitionsschlüssels, Ausfallszenarien, was um 3 Uhr nachts den Bereitschaftsdienst weckt.
- Abschluss – 5 Minuten. Engpässe, die du als Nächstes angehen würdest, was du überwachen würdest, was du bewusst ausgelassen hast. Mit bekannten Grenzen zu enden wirkt erfahren und nicht schwach.
Das Trade-off-Vokabular, an dem man Seniorität erkennt
Interviewer achten darauf, ob du diese Achsen von dir aus ansprichst:
| Kriterium | Der Satz, der punktet |
|---|---|
| Konsistenz vs. Verfügbarkeit | „Bei der Follower-Zahl würde ich veraltete Werte akzeptieren, beim Zahlungsjournal nicht: unterschiedliche Speicher für unterschiedliche Garantien.“ |
| Latenz vs. Kosten | „Wenn wir das oberste 1 % der Keys cachen, bedienen wir rund 90 % der Lesezugriffe. Alles zu cachen verdreifacht den Speicherbedarf für einen minimalen Gewinn bei der Trefferquote.“ |
| Push vs. Pull | „Fan-out-on-Write für normale Nutzer, Fan-out-on-Read für Promi-Accounts: ein Hybrid, gesteuert über die Follower-Zahl.“ |
| SQL vs. NoSQL | „Das Zugriffsmuster ist Key-Value über den Kurzcode, ganz ohne Joins. Das macht einen Wide-Column-Store hier vertretbar, nicht die Mode.“ |
| Synchron vs. asynchron | „Der Nutzer braucht die Bestätigung des Schreibvorgangs. Der Versand der Benachrichtigungen kann über eine Queue laufen und irgendwann zugestellt werden.“ |
Die Meta-Regel: Nenne nie eine Technologie, ohne die Eigenschaft zu nennen, mit der sie sich ihren Platz verdient. „Kafka“ ist ein Wort. „Ein partitioniertes Log, damit Consumer nach einem Ausfall erneut einlesen können“ ist ein Grund.
Die zehn häufigsten Aufgaben im System Design Interview und ihr jeweiliger Knackpunkt
- URL-Shortener. Knackpunkt: ID-Generierung (Zähler + Base62 vs. Hash + Kollisionsbehandlung) und Caching auf dem Lesepfad. Der klassische Einstieg. Rechne mit Nachfragen zu Analytics und Ablaufdaten.
- Chat-System (WhatsApp/Slack). Knackpunkt: Verbindungsverwaltung (WebSockets, Presence), Reihenfolge der Nachrichten pro Unterhaltung, Zustellgarantien und Lesebestätigungen, Offline-Synchronisierung.
- Newsfeed (Twitter/Instagram). Knackpunkt: Fan-out-Strategie und das Promi-Problem, Ranking als eigener Service, Paginierung über Cursor statt Offsets.
- Rate Limiter. Knackpunkt: Wahl des Algorithmus (Token Bucket vs. Sliding Window), verteiltes Zählen (Redis + Lua), Fail-open vs. Fail-closed und wo er sitzt (am Gateway oder pro Service).
- Dateispeicher (Dropbox/Drive). Knackpunkt: Chunking und Deduplizierung, Sync-Protokoll und Konfliktauflösung, Trennung von Metadaten und Blobs.
- Videoplattform (YouTube). Knackpunkt: Upload-Pipeline (Transcoding als asynchrone Jobs), CDN-Strategie, adaptive Bitrate und die Wirtschaftlichkeit des Speichers.
- Fahrtenvermittlung (Uber). Knackpunkt: Geo-Indexierung (Geohash/Quadtree), Schreibvolumen der Standort-Updates, Matching als zustandsbehafteter Service, Surge als Preis-Feed.
- Benachrichtigungssystem. Knackpunkt: Abstraktion über mehrere Kanäle (Push/E-Mail/SMS), Einstellungen und Obergrenzen pro Nutzer, Idempotenz und Retries mit Deduplizierung, Prioritäts-Queues.
- Verteilter Cache. Knackpunkt: Consistent Hashing, Verdrängungsstrategie, Cache-aside vs. Write-through, Schutz vor dem Thundering-Herd-Problem (Request Coalescing, TTLs mit Jitter).
- Metrik- und Monitoring-System. Knackpunkt: Schreibvolumen der Zeitreihen, Downsampling und Aufbewahrungsstufen, explodierende Tag-Kardinalität, Alert-Auswertung als Streaming-Berechnung.
Üb mindestens drei davon von Anfang bis Ende: laut, am Whiteboard oder in einem Dokument, im 45-Minuten-Takt. Ein Design zu erklären und eins aufzuschreiben sind verschiedene Fähigkeiten, und das Interview bewertet die Erklärung. Ein Probe-Interview mit einem KI-Interview-Assistenten liefert dir Feedback auf Transkript-Ebene, genau dort, wo deine Erklärung den Faden verloren hat. ChadFlow kann in einer Live-Runde außerdem das Fenster mit deinem Diagramm mitlesen und helfen, wenn eine Nachfrage kommt.
Fünf Arten, wie Kandidaten in dieser Runde scheitern
- Anforderungen überspringen. Das falsche System wunderschön zu entwerfen ist der häufigste Fehler. Dreißig Sekunden, um den Rahmen abzustecken, verhindern ihn.
- Schätzung als Show. Rechnen und die Zahlen dann nie verwenden. Wenn deine QPS-Schätzung nichts an deinem Design ändert, war sie nur Kulisse.
- Buzzword-Architektur. Kafka, Cassandra oder Kubernetes in den Raum werfen, ohne die oben beschriebene Begründung über Eigenschaften.
- Monologisieren. Die Runde testet Zusammenarbeit. Frag zwischendurch nach: „Soll ich bei der Speicherschicht tiefer gehen oder zur API übergehen?“
- Kein Plan für den Ausfall. Zu jeder Komponente, die du zeichnest, brauchst du eine Antwort auf „Was passiert, wenn sie ausfällt?“. Leg dir die Antwort zurecht, bevor du den Kasten zeichnest.
Erklär Designs wie jemand, der das nicht zum ersten Mal macht.
ChadFlow transkribiert deine Probe-Runden zum Design, coacht deine Erklärungen zwischen den Sessions und hilft live, indem es nur das ausgewählte Fenster mit deinem Diagramm sieht. In der Bildschirmfreigabe bleibt es unsichtbar.
ChadFlow laden