System-Design-Interview üben — allein, mit AI-Feedback

System Design ist die Runde, in der starke Engineers unterdurchschnittlich abschneiden und durchschnittliche Engineers gelegentlich einen Volltreffer landen, weil die Messlatte nicht „kennen Sie die Antwort“ ist — sondern „können Sie unter Zeitdruck laut über ein unscharfes Problem nachdenken“. Das können Sie trainieren. AI-Mocks geben Ihnen die seltene Kombination aus unbegrenzten Wiederholungen und konsistentem, strukturiertem Feedback.

Was in einer System-Design-Runde tatsächlich bewertet wird

Kandidaten nehmen an, der Score sei „haben Sie das richtige System entworfen“. Ist er nicht. Echte Interviewer bewerten fünf Dinge, und sie korrelieren nur schwach miteinander. Erstens: Haben Sie das Problem vor dem Entwurf geklärt — konkret, haben Sie nach Skalierung, Read/Write-Verhältnis, Latenzanforderungen und Constraints gefragt. Zweitens: Haben Sie eine Überschlagsrechnung gemacht, oder haben Sie auf „viel Traffic“ verwiesen, ohne Zahlen. Drittens: Haben Sie eine API und ein Datenmodell vorgeschlagen, bevor Sie Boxen gezeichnet haben. Viertens: Haben Sie eine Architektur entworfen, die zu den gerade definierten Anforderungen passt — nicht eine generische. Fünftens: Sind Sie bei mindestens einer Komponente in die Tiefe gegangen und haben Tradeoffs artikuliert, oder sind Sie eine Stunde lang an der Oberfläche geblieben.

Die meisten Kandidaten scheitern an Nr. 1 und Nr. 5. Sie fangen sofort an zu zeichnen, weil es sich produktiv anfühlt, und sie bleiben die ganze Stunde auf der „Boxen und Pfeile“-Ebene, ohne je eine einzige Entscheidung zu verteidigen. Die Lösung ist strukturell: Folgen Sie einem Framework, bei jedem Problem, bis das Framework automatisch sitzt.

Das Framework: sechs Phasen, bei jedem Problem

Nutzen Sie das bei jedem Design, auch bei denen, die einfach aussehen. Die ersten drei Male ist es langsamer und für immer danach schneller.

1. Klären (5 Min.). Funktionale Anforderungen — was tut das System, was tut es nicht. Nicht-funktionale — Skalierung, Latenz, Verfügbarkeit, Konsistenz. Constraints — Budget, Team, regulatorisch. Bestätigen Sie den Scope vor dem Entwurf. Der Interviewer gibt Ihnen manchmal absichtlich keinen Scope, um zu sehen, ob Sie fragen.
2. Schätzen (5 Min.). Nutzer, QPS, Speicher, Bandbreite. Schreiben Sie die Zahlen auf (laut, da Sie ja sprechen). 100 Mio. DAU, 10 Reads pro Nutzer pro Tag, 80/20-Read/Write-Split — das sind grob 12K QPS Read, 3K QPS Write. Sie müssen nicht richtig liegen; Sie müssen plausibel sein.
3. API (5 Min.). Definieren Sie die 3–5 wichtigsten Endpoints. Methode, Pfad, Params, Response-Shape. Dieser Schritt zählt mehr, als Kandidaten erkennen, weil er Sie zwingt, Ihre Substantive zu benennen. „POST /shorten“ mit einem Body von {url, custom_alias?} ist konkreter als ein Verweis auf „den URL-Service“.
4. Datenmodell (5 Min.). Tabellen oder Document-Schemas, Keys, Indexes. Nennen Sie Ihre Datenspeicher-Wahl (Postgres, DynamoDB, Cassandra) und verteidigen Sie sie in einem Satz. Die Wahl ist Teil des Datenmodells — keine separate Entscheidung später.
5. Architektur (15 Min.). Jetzt zeichnen Sie Boxen. Client, Load Balancer, API Gateway, Services, Caches, Message Queues, Datenbanken. Gehen Sie den Read-Pfad und den Write-Pfad getrennt durch. Versuchen Sie nicht, das perfekte Diagramm im ersten Durchgang zu zeichnen — skizzieren Sie es, dann fügen Sie Boxen hinzu, wenn Sie merken, dass Sie sie brauchen.
6. Deep Dive + Tradeoffs (15 Min.). Der Interviewer wird sagen „lassen Sie uns bei X in die Tiefe gehen“. Oder er tut es nicht, und Sie sollten es von sich aus anbieten. Wählen Sie die interessanteste Komponente und erklären Sie im Detail, wie sie funktioniert — Replikationsstrategie, Eviction Policy, Skalierungsansatz. Enden Sie mit expliziten Tradeoffs: „wir haben Eventual Consistency gewählt, weil der Use Case 30 Sekunden Veraltung toleriert und die Alternative eine Verdreifachung der Kosten gewesen wäre“.

Gängige Designs, die Sie aus dem Stand beherrschen sollten

URL-Shortener

Der täuschend einfache. Das System ist simpel — eine kurze ID generieren, das Mapping speichern, beim Lookup umleiten. Das Interview ist schwer, weil der Interviewer Sie bei jedem Detail unter Druck setzt. Wie generieren Sie IDs? (Zufällig vs. inkrementierend vs. Base62-Hash — jedes hat Tradeoffs.) Welche Datenbank? (KV-Store wie Redis für Hot Reads, relational für Analytics.) Wie behandeln Sie Kollisionen? (Retry mit längerer ID oder einen Pool pro Node vorallokieren.) Wie ist das Read/Write-Verhältnis? (Mindestens 100:1 — entwerfen Sie für Read-lastig.) Caching-Strategie? Read-Through mit hoher TTL, da URLs sich selten ändern. Dieses Design deckt vielleicht 40 % der Themen ab, die auch in anderen Designs auftauchen.

Social Feed (Twitter-Stil)

Fan-out ist die kanonische Frage. Push (Tweet schreiben → in alle Follower-Timelines schreiben) vs. Pull (Tweet schreiben → zur Query-Zeit aus der Following-Liste lesen). Push optimiert die Read-Latenz auf Kosten der Write-Amplification — schlecht für Promi-Accounts mit 10 Mio. Followern. Pull optimiert die Write-Kosten — schlecht für Nutzer mit Tausenden Follows. Die Antwort aus der Praxis ist hybrid: Push für normale Nutzer, Pull für Promis. Seien Sie bereit zu erklären, welchen Schwellenwert Sie wählen würden (z. B. Follower-Zahl > 10K löst Pull-Verhalten aus) und warum.

Chat-System

Drei interessante Subsysteme: Message Storage, Delivery und Presence. Storage: nach Conversation-ID partitionieren, Messages in Append-only-Logs speichern, kalte Conversations archivieren. Delivery: WebSocket-Verbindung pro aktivem Nutzer, Message Queue für Offline-Delivery, Push-Notifications für Mobile. Presence: ephemer, Heartbeat-basiert, Eventually Consistent. Der Interviewer setzt Sie bei Message Ordering unter Druck (kausal? total? Per-Conversation-Total-Ordering reicht meist) und bei Delivery Guarantees (At-least-once ist der Standard — behandeln Sie Dedup auf dem Client).

AI-Mocks speziell für System Design nutzen

Wählen Sie den „Full Interview“-Modus und sagen Sie der AI, dass Sie eine System-Design-Runde wollen, kein Screening. Geben Sie das Design an („URL-Shortener“, „Instagram-Feed“) oder lassen Sie es die AI wählen. Gehen Sie das Framework laut durch — beschreiben Sie, was Sie zeichnen würden, gehen Sie den Read-Pfad durch, erklären Sie Tradeoffs, während Sie sie treffen. Die AI hakt mit denselben Arten von Fragen nach, die ein echter Interviewer stellt: „was passiert, wenn der Cache ausfällt?“, „wie behandeln Sie einen Hot Key?“, „was ist Ihre Replikationsstrategie und was ist der Failure Mode?“. Antworten Sie in vollständigen Sätzen mit expliziten Tradeoffs, denn so wird die echte Runde bewertet.

Ein konkreter Trick: Sagen Sie der AI, sie solle als Senior-Interviewer bei einem FAANG agieren. Sie wird bei Annahmen härter nachhaken und sich weigern, generische Antworten zu akzeptieren. Das ist die hebelstärkste Einstellung für Senior+-Kandidaten, weil Sie üben müssen, Entscheidungen gegen Gegenwind zu verteidigen, nicht nur sie zu nennen.

Was das AI-Feedback nicht erfasst (und was man dagegen tut)

AI-Feedback ist hervorragend bei Struktur, Tradeoff-Artikulation und fehlenden Komponenten. Es ist schwächer bei der Diagrammqualität (Sie beschreiben, statt zu zeichnen) und dabei, ob Ihre numerischen Schätzungen für die spezifische Skalierung des jeweiligen Unternehmens realistisch sind. Mildern Sie das, indem Sie ein bis zwei Sessions mit einem echten Whiteboard machen — öffnen Sie excalidraw auf einem zweiten Monitor und zeichnen Sie, während Sie reden. Kombinieren Sie AI-Mocks mit ein bis zwei Peer- oder Coach-Runden in der letzten Woche vor dem echten Interview, besonders wenn Sie auf Staff oder Principal abzielen.

Für die Teile, in denen die AI großartig ist: Struktur und Tradeoff-Artikulation. Lesen Sie das bewertete Feedback nach jeder Session erneut und schreiben Sie zwei konkrete Änderungen für die nächste auf. Zwei Änderungen pro Session summieren sich schnell — drei Sessions, und Sie sind messbar strukturierter als 80 % der Kandidaten, die in den Raum gehen.

Häufig gestellte Fragen