System Design Interview: Framework und Vorgehen
Strukturiertes Vorgehen für Platform-System-Design-Interviews.
Lernziele
Nach dieser Lektion hast du ein 45-Minuten-Framework für Platform-System-Design-Interviews, das über das generische „Requirements → API → DB”-Schema hinausgeht. Du kannst die ersten zehn Minuten strukturiert nutzen, NFRs plattformspezifisch priorisieren, Trade-offs während du zeichnest kommunizieren und souverän reagieren, wenn du in einer Ecke feststeckst. Du kennst den Unterschied zwischen einem Interview, das Tools testet, und einem, das Architektur-Denken testet.
Das Problem: Du kennst Kubernetes — und scheitert trotzdem
Du hast Backstage deployed, Kyverno-Policies geschrieben, Multi-Cluster mit Argo CD betrieben. Im Interview kommt: „Entwirf eine interne Developer Platform für 200 Teams.” Du beginnst mit „Also, wir nehmen Kubernetes, ein Portal, GitOps…” — und nach zwanzig Minuten merkst du, dass du nie gefragt hast, ob es regulierte Workloads gibt, wie viele Deployments pro Tag anfallen oder ob Brownfield oder Greenfield.
Das ist kein Wissensproblem. Es ist ein Prozessproblem. Platform-System-Design-Interviews bewerten vier Dinge: Strukturiertes Denken, Kontext-Sensibilität, Trade-off-Kommunikation und Priorisierung unter Zeitdruck. Lektion 6 lieferte das Grundgerüst — hier geht es um die Interview-Ausführung: Timing, Formulierungen, Recovery-Taktiken.
Die ersten zehn Minuten: Scope vor Lösung
Minute 0–10 entscheidet oft über Strong Hire vs. No Hire. Dein Ziel: fünf bis sieben klärende Fragen, bevor du eine Box zeichnest. Sage die Methode laut:
„Bevor ich skizziere, kläre ich kurz den Scope — das verändert jede Architekturentscheidung.”
Pflichtfragen für Plattform-Design:
- Teams und Services — Wie viele Teams? Wie viele Services pro Team? Wachstum?
- Workload-Typen — Web, Batch, ML, Stateful? Regulierte Daten?
- Compliance — SOC 2, PCI, On-Prem-Pflicht, Data Residency?
- Organisation — Zentrales Platform-Team? Stream-Aligned? Bestehende Tools?
- Schmerzpunkt — Was soll die Plattform primär lösen? (Time-to-Production, Kosten, Security, Standardisierung?)
- Constraints — Eine Cloud oder Multi-Cloud? Bestehende Cluster (Brownfield)?
Schreibe die Antworten sichtbar auf — der Interviewer sieht, dass du zuhörst. Dann fasse zusammen: „Okay — 80 Teams, kein PCI, Hauptschmerz ist vier Wochen bis Production, AWS-only, Greenfield. Dann fokussiere ich MVP auf Self-Service-Provisioning und Golden-Path-Delivery.”
NFRs zuerst: Skalierung, Tenancy, Compliance
Funktionale Anforderungen (Portal, CI/CD, Observability) sind leicht — jeder nennt sie. Nicht-funktionale Anforderungen trennen Senior von Junior:
| NFR | Plattform-Frage | Beispiel-Zielwert |
|---|---|---|
| Verfügbarkeit | Was darf die Plattform-API ausfallen? | 99,9 % — Workloads laufen weiter |
| Tenancy | Shared Cluster oder dediziert? | Namespace-Isolation + Quotas |
| Blast Radius | Was darf wie viele Teams treffen? | Control-Plane-Ausfall ≠ Workload-Ausfall |
| Compliance | Welche Controls sind Pflicht? | SOC 2 → GitOps als Change-Management |
| Kosten | Chargeback nötig? | Showback ab Tag eins |
Nenne mindestens drei NFRs explizit, bevor du zeichnest. Formuliere sie als Entscheidungskriterien: „Weil kein PCI, akzeptiere ich Shared Cluster pro Umgebung — bei PCI würde ich umschwenken.”
Trade-offs während du zeichnest — laut denken
Der häufigste Fehler: schweigend zeichnen und am Ende eine fertige Architektur präsentieren. Besser: jede Box begründen, jede Alternative kurz verwerfen.
Beispiel-Monolog beim Zeichnen:
„Hier oben das Management-Cluster — Control Plane mit Portal, GitOps, Policy. Trennung vom Data Plane, damit ein Plattform-Upgrade Team-Workloads nicht anfasst. Alternative wäre alles in einem Cluster — spart Kosten, aber Blast Radius ist zu groß für 80 Teams.”
Das Vier-Elemente-Format (aus Lektion 6): Kontext → Kriterium → Entscheidung → Grenze. Zwei Sätze reichen.
Interviewer-Einwand simulieren: „Warum nicht ein Cluster pro Team?” — Antwort: „Bei 80 Teams sind 80 Cluster ein Betriebs-Overhead, den ein Platform-Team von 8 Leuten nicht trägt. Namespace-Isolation mit Quotas und NetworkPolicies reicht ohne PCI. Grenze: Sobald regulierte Workloads dazukommen, eigener Cluster für die Zone.”
Wenn du feststeckst: Recovery ohne Panik
Jeder hängt irgendwann. Drei Recovery-Taktiken:
Scope reduzieren. „Ich fokussiere den Deep Dive auf Tenancy und lasse Observability-Details für Phase 2 — passt das?” Zeigt Priorisierung, nicht Schwäche.
Annahme explizit machen. „Ich nehme an, OIDC-Integration existiert — wenn nicht, wäre Identity mein erster MVP-Block.” Der Interviewer korrigiert oder bestätigt.
Zurück zu Anforderungen. „Welche NFR ist hier wichtiger — Isolation oder Kosten?” Lässt den Interviewer mitentscheiden — und gibt dir Richtung.
Was du nicht tun solltest: Tool-Namen raten, als wäre es ein Quiz; „Ich weiß nicht” ohne nächsten Schritt; die Zeichnung verstecken und neu anfangen.
Praxis
Spiele ein vollständiges 45-Minuten-Interview allein — Timer, Whiteboard oder Papier:
Prompt: „Entwirf eine IDP für einen Versicherer: 60 Teams, PCI für einen Teil der Workloads, Azure, Brownfield mit Jenkins, Hauptschmerz: uneinheitliche Deployments.”
| Phase | Minuten | Aufgabe |
|---|---|---|
| Scope | 0–10 | Sieben Fragen stellen; Antworten notieren; MVP benennen |
| FR/NFR | 10–18 | Zwei FRs priorisieren; drei NFRs mit Zielwerten |
| Architektur | 18–32 | Control/Data Plane zeichnen; jede Box begründen |
| Deep Dive | 32–40 | PCI-Isolation: Shared vs. dedizierter Cluster — Vier-Elemente-Antwort |
| Risiken | 40–45 | Zwei Risiken + Gegenmaßnahmen |
Nimm dich auf (Handy, Voice Memo) und höre danach: Hast du Trade-offs genannt? Warst du zu lange still?
Typische Stolperfallen
Tool-Stack in Minute zwei. „Kubernetes, Argo, Backstage” ohne Anforderungsbezug wirkt unreif.
Keine Größenordnungen. „Viele Teams” reicht nicht — 60 Teams × 8 Services × 3 Deploys/Tag = ~1 400 Deploys/Tag sagt dir, wo der Engpass liegt.
Ein Diagramm für alles. Control Plane und Data Plane vermischen — der Interviewer verliert den Faden.
Deep Dive verweigern. „Darauf komme ich später” ohne Priorisierung wirkt ausweichend.
Perfektionismus. Lieber MVP-Architektur mit Trade-offs als vollständiges Enterprise-Design in 45 Minuten.
Interview-Vorbereitung
Deine Eröffnung, wenn die Aufgabe kommt:
„Ich strukturiere so: erst Scope und NFRs, dann High-Level-Architektur mit Control/Data-Plane-Trennung, dann einen Deep Dive Ihrer Wahl. Passt das?”
Follow-ups, die fast immer kommen:
- „Was ist dein MVP in den ersten drei Monaten?” — Provisioning + Golden Path, nicht Portal-Feinschliff.
- „Wie isolierst du Mandanten?” — Namespace, Quota, NetworkPolicy; Cluster bei PCI.
- „Was machst du bei Plattform-Ausfall?” — Workloads laufen; kein neues Deploy — degradierter Modus.
Zusammenfassung
Platform-System-Design-Interviews gewinnst du mit Struktur: Scope klären, NFRs explizit machen, Control Plane und Data Plane trennen, Trade-offs laut begründen und bei Feststecken Scope reduzieren oder Annahmen benennen. Das Framework aus Lektion 6 ist dein Inhalt — diese Lektion ist deine Choreografie. In den nächsten drei Lektionen spielst du konkrete Cases durch: Multi-Tenant für 100 Teams, Enterprise-IDP für 500+ Entwickler, Legacy-Migration.