System Design Interview: Wie man die Antwort strukturiert

Suchintention: Mid-Level- bis Senior-Engineers, die verteilte Systeme kennen, aber einfrieren, wenn sie sie live vor einem Interviewer entwerfen sollen.

Warum gute Engineers beim System Design Interview scheitern

Du hast verteilte Systeme gebaut. Du hast Produktionsausfälle debuggt. Du weißt, was ein CDN ist. Und trotzdem wird dein Kopf leer, wenn jemand sagt: „Entwirf Twitter."

Das Problem ist nicht das Wissen – es ist die Struktur. System Design-Fragen sind absichtlich offen gestellt. Ohne ein klares Framework springst du zwischen Komponenten hin und her, vergisst Anforderungen zu klären und läufst aus der Zeit, bevor du die wichtigen Teile behandelt hast.

Interviewer bewerten nicht dein finales Diagramm. Sie beobachten, wie du denkst: Sammelst du Anforderungen? Schlägst du ein Design vor? Identifizierst du Engpässe? Denkst du über Trade-offs nach? Das ist es, was das System Design Interview wirklich testet.

Das 5-Schritte-Framework für jedes System Design Interview

Schritt 1: Anforderungen klären (3–5 Minuten)

Bevor du etwas zeichnest, stelle Fragen. Das ist keine Taktik zum Zeitschinden – es ist der wichtigste Teil.

Funktionale Anforderungen – was das System leisten muss:

• Was sind die zentralen Benutzeraktionen? (Posten, Lesen, Suchen, Folgen?)
• Welche Anwendungsfälle liegen außerhalb des Scope?

Nicht-funktionale Anforderungen – wie das System sich verhalten muss:

• Skalierung: Wie viele täglich aktive Nutzer? Lese- oder schreiblastig?
• Latenzziele: Was ist für die Hauptbenutzeraktion akzeptabel?
• Verfügbarkeit: Welches Uptime-SLA gilt? Können wir kurze Ausfälle bei Deployments tolerieren?
• Konsistenz: Starke Konsistenz erforderlich oder ist Eventual Consistency in Ordnung?

Schreibe die Zahlen auf. „1M täglich aktive Nutzer, 100:1 Lese-/Schreibverhältnis, p99 < 200ms für Lesevorgänge" – das prägt jede architektonische Entscheidung.

Überspringe diesen Schritt nicht, auch wenn die Aufgabe klar erscheint. Interviewer lassen absichtlich Unklarheiten offen, um zu sehen, ob du nachfragst.

Schritt 2: Skalierung abschätzen (2–3 Minuten)

Überschlagsrechnungen erden dein Design. Für ein leselastiges System mit 10M DAU:

• Annahme: 50 Lesevorgänge/Tag pro Nutzer → 500M Lesevorgänge/Tag → ~6.000 Lesevorgänge/Sekunde
• Speicher: Wenn jeder Datensatz 1KB groß ist und 10M neue Datensätze/Tag gespeichert werden → 10GB/Tag → 3,6TB/Jahr

Diese Zahlen sagen dir, ob du eine einzelne Datenbank oder Sharding brauchst, ob ein Cache-Node ausreicht und wie deine CDN-Strategie aussehen soll.

Schritt 3: High-Level-Design (10–12 Minuten)

Jetzt zeichnen. Beginne mit dem einfachsten Design, das deine Anforderungen erfüllt. Ein gutes High-Level-Design enthält für die meisten Systeme:

• Client → API Gateway → Anwendungsdienste
• Datenbanken – welcher Typ und warum (relational, NoSQL, Zeitreihen)?
• Cache – was wird gecacht und warum?
• Asynchrone Verarbeitung – wo passt eine Message Queue rein?
• CDN – für statische Inhalte oder geografisch verteilte Lesevorgänge

Beispiel für einen URL-Shortener in der Skalierung:

1. Schreibpfad: Client → API → Anwendungsserver → DB (Kurzlink:Langlink-Mapping schreiben) + Cache
2. Lesepfad: Client → CDN → Load Balancer → App-Server → Cache (Redis) → DB bei Cache-Miss
3. Kurzlink-Generierung: Zählerbasierte ID mit Base-62-Encoding oder ein verteilter ID-Generator (Snowflake)

Erkläre deine Entscheidungen laut: „Ich verwende hier PostgreSQL, weil die Daten relational sind und wir starke Konsistenz beim Schreiben brauchen. Für Lesevorgänge schalte ich Redis davor."

Schritt 4: Deep-Dives (10–15 Minuten)

Nach dem High-Level wird der Interviewer dich typischerweise zu den Bereichen führen, die ihm am wichtigsten sind. Häufige Themen:

• Datenbankschema-Design – welche Tabellen, Indizes, Sharding-Strategie?
• Caching-Strategie – Cache-aside vs. Write-through? TTL? Cache-Invalidierung?
• Hotspot-Behandlung – was passiert, wenn die Posts eines prominenten Nutzers 10M Aufrufe erhalten?
• Konsistenz vs. Verfügbarkeit – wo machst du diesen Trade-off explizit?
• Data Fan-out – bei sozialen Feeds: wie propagierst du Schreibvorgänge an Follower?

Gehe in die Tiefe, wenn danach gefragt wird. Der Interviewer möchte sehen, dass du über „einen Cache vor die Datenbank schalten" hinausgehst zu „hier ist die Eviction Policy, so behandle ich Cache Stampedes, das ist der Trade-off, den ich eingehe."

Schritt 5: Trade-offs und Alternativen (5 Minuten)

Schließe damit ab, was du bewusst weggelassen oder vereinfacht hast. Das trennt gute Kandidaten von großartigen.

„Ich habe hier Eventual Consistency gewählt, um besseren Schreibdurchsatz zu erzielen – aber wenn das Unternehmen verlangt, dass jeder Lesevorgang den neuesten Schreibvorgang widerspiegelt, müsste ich das mit synchroner Replikation neu durchdenken, was Latenz hinzufügt."

Das signalisiert Engineering-Reife: Du verstehst, dass jede architektonische Entscheidung ein Trade-off ist, keine richtige Antwort.

Häufige System Design-Interviewfragen und was sie wirklich testen

Die größten Fehler beim System Design Interview

Direkt zu Code oder Diagrammen springen. Beginne jedes Mal mit Anforderungen, auch wenn das Problem offensichtlich erscheint.

Das perfekte System entwerfen. Es gibt kein perfektes System. Der Interviewer möchte Trade-off-Überlegungen sehen, kein Lehrbuchdiagramm.

Schweigen. Erkläre dein Denken laut. Wenn du zwei Ansätze abwägst, sag es. „Ich wähle zwischen X und Y – X bietet bessere Schreibleistung, aber Y lässt sich bei Lesevorgängen leichter skalieren. Bei unserem 100:1-Leseverhältnis entscheide ich mich für Y."

Skalierung ignorieren. Jede Entscheidung sollte auf deine Zahlen zurückführen. „Das funktioniert bei 1K QPS, aber bei 100K QPS müssten wir sharden – so würde ich das angehen."

Jetzt üben

Das Framework zu kennen und es live unter Interviewerdruck anzuwenden sind zwei sehr unterschiedliche Dinge.

Probiere eine kostenlose Session auf Interview Sparring →