System Design Framework

Lernziele

Nach dieser Lektion hast du ein wiederholbares Framework für Platform-System-Design-Interviews: sechs Phasen mit fester Zeiteinteilung für 45 Minuten. Du weißt, was in jeder Phase passiert, welche Fehler dort lauern und woran Interviewer erkennen, ob du auf Senior-Niveau denkst. Dieses Framework ist die Grundlage für alle Cases in diesem Lernpfad — jede folgende Lektion spielt es an einem konkreten Szenario durch.

Warum du ohne Framework verlierst

Die typische Aufgabenstellung klingt harmlos: „Designe eine Kubernetes-Plattform für 50 Teams.” Kandidaten ohne Plan reagieren auf zwei Arten, beide tödlich. Die einen fangen sofort an zu zeichnen — nach zehn Minuten steht ein Diagramm voller Tool-Logos, das eine Frage beantwortet, die niemand gestellt hat. Die anderen erstarren, weil die Aufgabe zu groß wirkt, und verlieren fünf Minuten mit Schweigen.

Beides passiert, weil Platform-Design-Aufgaben absichtlich unterspezifiziert sind. Der Interviewer lässt Anforderungen offen, weil das Klären dieser Anforderungen Teil der Prüfung ist. Im echten Job bekommst du auch keine fertige Spec — du bekommst „die Entwickler beschweren sich über Deployments” und musst daraus ein Problem destillieren. Ein Framework gibt dir in dieser Unsicherheit Halt: Du weißt immer, in welcher Phase du bist und was als Nächstes kommt. Das nimmt Druck raus und wirkt nach außen souverän.

Die sechs Phasen mit Zeitbudget

Für ein 45-Minuten-Interview hat sich diese Aufteilung bewährt:

Phase 1 — Anforderungen klären (5–8 Min). Bevor du irgendetwas zeichnest, stellst du Fragen. Vier Kategorien decken fast alles ab: Nutzer (Wer benutzt die Plattform — Entwickler, Ops, Security? Wie viele?), Scale (Wie viele Teams, Services, Cluster, Requests?), Constraints (Welche Cloud? Bestehende Tools? Budget? Compliance-Vorgaben wie SOC 2 oder DSGVO?) und Erfolgskriterien (Woran wird die Plattform gemessen — DORA-Metriken, Adoption, Ticket-Reduktion?). Fasse am Ende laut zusammen: „Ich designe also für X Teams auf AWS mit Anforderung Y — korrekt?” Diese Zusammenfassung ist dein Vertrag mit dem Interviewer.

Phase 2 — Grobe Zahlen (3–5 Min). Keine Mathematik-Show, sondern Größenordnungen: 50 Teams × 10 Services × 3 Pods ≈ 1.500 Pods — das passt locker in einen Cluster, die Frage ist also Isolation, nicht Kapazität. Solche Rechnungen zeigen, dass deine Architektur auf Zahlen steht, nicht auf Gewohnheit.

Phase 3 — High-Level-Design (10 Min). Jetzt zeichnest du: 4–7 Boxen, klar beschriftete Pfeile. Wichtiger als die Boxen ist der Datenfluss — erzähle eine Geschichte: „Ein Entwickler stellt einen Request im Portal, der erzeugt einen Commit im GitOps-Repo, der Controller rollt aus…” Wer nur statische Boxen malt, hat ein Inventar; wer Flüsse erklärt, hat eine Architektur.

Phase 4 — Deep Dive (12–15 Min). Du vertiefst zwei, maximal drei Komponenten. Welche? Frag den Interviewer: „Soll ich tiefer auf die Tenant-Isolation oder auf den Delivery-Pfad eingehen?” Das ist keine Schwäche, sondern Steuerung — du findest heraus, was bewertet wird, statt zu raten.

Phase 5 — Trade-offs und Alternativen (5 Min, oft verwoben mit Phase 4). Jede größere Entscheidung bekommt das Muster: „Ich wähle X wegen Y und akzeptiere dafür Nachteil Z. Alternative wäre A — die würde ich nehmen, wenn Bedingung B gilt.” Damit zeigst du, dass du Optionen abgewogen hast statt eine Default-Lösung abzuspulen.

Phase 6 — Failure Modes und Ausblick (3–5 Min). Schließe proaktiv: Was fällt aus, und was passiert dann? Was ist der Single Point of Failure? Wie würdest du das in Phasen ausrollen? Kandidaten, die das ungefragt ansprechen, heben sich deutlich ab — die meisten müssen dazu gedrängt werden.

Was Interviewer tatsächlich bewerten

Die Bewertungsbögen unterscheiden sich zwischen Firmen, aber vier Dimensionen tauchen fast immer auf. Erstens Strukturierung: Zerlegst du ein vages Problem in handhabbare Teile? Zweitens Begründungstiefe: Kannst du jede Entscheidung mit einem Warum versehen, oder antwortest du auf „Warum Argo CD?” mit „das nutzen alle”? Drittens Kommunikation: Kann man dir folgen, bindest du den Interviewer ein, reagierst du auf Hinweise? Viertens Pragmatismus: Designst du für die gegebenen Anforderungen oder für ein Fantasie-Google?

Auffällig ist, was nicht prominent bewertet wird: das perfekte Tool. Ob du Argo CD oder Flux wählst, ist fast egal — ob du den Unterschied begründen kannst, ist entscheidend. Für Platform-Rollen kommt eine fünfte Dimension dazu: Produktdenken. Eine Plattform hat Nutzer, und die Frage „Wie misst du, ob die Plattform ihren Job macht?” gehört in deine Antwort, nicht erst in den Follow-up.

Das Framework an dein Level anpassen

Das Zeitbudget oben ist ein Startpunkt, kein Gesetz. Bei einer 60-Minuten-Runde dehnst du vor allem den Deep Dive. Wenn der Interviewer früh unterbricht und in eine Komponente zieht, folge ihm — das Framework ist deine Landkarte, aber er bestimmt die Route. Sage dann explizit: „Ich parke die Capacity-Abschätzung und komme darauf zurück, wenn relevant” — so geht nichts verloren und der Interviewer sieht, dass du den Überblick behältst.

Für Senior- und Staff-Level verschiebt sich der Schwerpunkt: weniger „welches Tool”, mehr Organisation und Evolution. Wer betreibt was? Wie migrierst du von Bestand? Was ist Phase 1 versus Phase 3 des Rollouts? Plane mental ein Drittel deiner Deep-Dive-Zeit für solche Fragen ein, wenn du dich auf eine Lead-Rolle bewirbst.

Praxis

Nimm die Aufgabe „Designe eine interne Plattform, mit der 30 Teams ihre Services selbst deployen können” und spiele sie 45 Minuten am Whiteboard (oder auf Papier) komplett durch — laut, mit Timer, alle sechs Phasen. Diese fünf Punkte müssen vorkommen:

1. Mindestens sechs Klärungsfragen aus allen vier Kategorien (Nutzer, Scale, Constraints, Erfolgskriterien) — beantworte sie dir selbst mit plausiblen Annahmen.
2. Eine Größenordnungsrechnung (Pods, Cluster, Deployments/Tag).
3. Ein Diagramm mit maximal sieben Boxen und einem laut erzählten Datenfluss.
4. Zwei Deep Dives mit je einem Trade-off im Format „X wegen Y, akzeptiere Z, Alternative A falls B”.
5. Ungefragt: zwei Failure Modes und ein dreiphasiger Rollout-Plan.

Stoppe nach jeder Phase die Zeit und notiere die Abweichung vom Budget. Die meisten überziehen Phase 3 massiv — das ist die wichtigste Erkenntnis dieser Übung.

Typische Stolperfallen

Zeichnen vor dem Fragen. Der häufigste Fehler überhaupt. Wer in Minute 2 schon Boxen malt, designt am Problem vorbei — und Interviewer werten genau das als Junior-Signal.

Der 25-Minuten-Deep-Dive in eine Komponente. Du verlierst dich in Vault-Auth-Details und hast am Ende keine Gesamtarchitektur gezeigt. Breite zuerst, Tiefe gezielt — und den Interviewer wählen lassen, wo.

Tool-Aufzählung statt Architektur. „Ich nehme Backstage, Argo CD, Crossplane, Kyverno, Vault…” ist keine Antwort, sondern eine Einkaufsliste. Jedes genannte Tool muss eine Aufgabe im Datenfluss haben, sonst lass es weg.

Das Framework als Korsett. Wer stur seine sechs Phasen abarbeitet, während der Interviewer dreimal in Richtung Netzwerk-Isolation lenkt, signalisiert: Ich höre nicht zu. Das Framework strukturiert dich, nicht das Gespräch.

Interview-Vorbereitung

Deine Kernbotschaft, wenn jemand fragt, wie du an Design-Aufgaben herangehst: Erst Anforderungen und Zahlen, dann ein grobes Bild mit erklärtem Datenfluss, dann gezielte Tiefe mit explizit benannten Trade-offs, am Schluss Failure Modes — und über allem ständige Abstimmung mit dem Gegenüber.

Rechne mit diesen Follow-ups:

• „Wie teilst du 45 Minuten ein?” — Etwa 7 Minuten Anforderungen, 4 Zahlen, 10 High-Level, 15 Deep Dive, der Rest Trade-offs und Failure Modes; flexibel, wenn der Interviewer lenkt.
• „Was klärst du zuerst, bevor du zeichnest?” — Nutzer, Scale, Constraints, Erfolgskriterien — und dann eine laute Zusammenfassung als Vertrag.
• „Was machst du, wenn du eine geforderte Technologie nicht kennst?” — Ehrlich sagen, auf Prinzipien-Ebene weiterdesignen („eine Komponente, die X leistet”) und Parallelen zu bekannten Tools ziehen.
• „Woran scheitern Kandidaten am häufigsten?” — Sie überspringen die Anforderungsklärung und liefern eine generische Architektur ohne Bezug zur Aufgabe.

Zusammenfassung

Platform-Design-Aufgaben sind bewusst vage — das Framework macht daraus einen kontrollierten Prozess: Klären → Schätzen → Skizzieren → Vertiefen → Abwägen → Brechen, mit festen Zeitbudgets und dem Interviewer als Navigator. Bewertet werden Struktur, Begründung, Kommunikation und Pragmatismus, nicht die Tool-Wahl. In der nächsten Lektion bekommst du die Checkliste dazu: die konkreten Punkte, die in jeder Phase abgehakt sein müssen, und die Fallstricke, die auch gut vorbereitete Kandidaten erwischen.