System Design Framework für Platform Engineers

Lernziele

Nach dieser Lektion hast du ein wiederholbares Vorgehen für Plattform-System-Design: vom Scope-Klären über funktionale und nicht-funktionale Anforderungen bis zur Architektur-Skizze mit explizit benannten Trade-offs. Du kennst die Trennung von Control Plane und Data Plane als Grundmuster jeder Plattform-Architektur und kannst ein 45-Minuten-Design-Interview strukturiert durchspielen, statt sofort Kästchen zu zeichnen.

Das Problem: Design-Interviews ohne Plan

„Entwirf eine interne Developer Platform für unser Unternehmen.” Mit dieser Aufgabe beginnen viele Plattform-Interviews — und die häufigste Art zu scheitern ist nicht fehlendes Wissen, sondern fehlende Struktur. Kandidaten springen direkt zur Lösung („Also, wir nehmen Kubernetes, ArgoCD, Backstage…”) und merken nach zwanzig Minuten, dass sie für eine Firma mit acht Entwicklern eine Multi-Region-Architektur entworfen haben. Tool-Aufzählung ohne Anforderungsbezug ist das sicherste Signal für fehlende Senior-Reife.

Klassische System-Design-Frameworks (Requirements → Schätzung → API → Datenmodell → Architektur) helfen, passen aber nicht eins zu eins: Bei Plattformen ist der Kunde intern, die Last besteht nicht aus Endnutzer-QPS, sondern aus Teams, Services und Deployments, und der größte Risikofaktor ist der Blast Radius — ein Plattform-Fehler trifft alle Teams gleichzeitig. Du brauchst eine angepasste Schrittfolge.

Sechs Schritte für Platform System Design

Schritt 1 — Scope klären. Bevor du irgendetwas zeichnest, stellst du Fragen: Wie viele Teams und Services? Welche Workload-Typen (Web-Services, Batch, ML)? Reguliertes Umfeld? Eine Cloud oder mehrere? Brownfield oder grüne Wiese? Diese fünf Antworten verändern jede nachfolgende Entscheidung — und das Fragen selbst ist Teil der Bewertung.

Schritt 2 — Funktionale Anforderungen. Was muss die Plattform können? Typisch: Self-Service-Provisioning von Umgebungen, Golden-Path-Delivery (CI/CD), Service-Catalog und Discovery, Observability als Service, Identity und Secrets. Priorisiere laut: „Für den Start fokussiere ich Provisioning und Delivery, der Rest kommt iterativ” — das zeigt TVP-Denken aus Lektion 5.

Schritt 3 — Nicht-funktionale Anforderungen. Hier trennt sich Mittelmaß von stark: Verfügbarkeit (welche SLOs für Plattform-API und Workloads?), Sicherheit und Mandantentrennung, Compliance (Data Residency?), Kosten (Showback/Chargeback nötig?), und — plattformspezifisch — Blast Radius: Welche Komponente darf maximal wie viele Teams gleichzeitig beeinträchtigen? Nenne mindestens drei NFRs explizit, bevor du zeichnest.

Schritt 4 — Größenordnungen. Keine QPS-Akrobatik, aber Hausnummern: 50 Teams × 10 Services × 5 Deployments/Tag ≈ 2 500 Deployments täglich — das sagt dir, dass die CI-Strecke das heißeste Teil wird. Anzahl Cluster, Umgebungen pro Team, erwartetes Wachstum.

Schritt 5 — High-Level-Architektur. Jetzt erst das Diagramm — dazu gleich mehr beim Control-Plane-Muster.

Schritt 6 — Deep Dives mit Trade-offs. Der Interviewer pickt ein bis zwei Themen heraus (Tenancy, GitOps-Flow, Policy Enforcement, Disaster Recovery). Hier zählt, dass du pro Entscheidung Alternativen und Kriterien nennst, nicht die „richtige” Antwort.

Das Grundmuster: Control Plane und Data Plane trennen

Fast jede ernsthafte Plattform-Architektur trennt zwei Welten: Die Control Plane ist der Ort, an dem die Plattform verwaltet wird — Developer Portal, GitOps-Controller, Policy-Engine, Provisioning-Logik, typischerweise in einem dedizierten Management-Cluster. Die Data Plane (oft: Workload-Cluster) führt die Anwendungen der Teams aus.

Warum die Trennung das Standardmuster ist:

• Blast Radius: Fällt die Control Plane aus, laufen die Workloads weiter — es können nur keine neuen Deployments oder Umgebungen erzeugt werden. Ein degradierter Zustand statt eines Totalausfalls.
• Unabhängige Lebenszyklen: Das Management-Cluster lässt sich upgraden, ohne Team-Workloads anzufassen — und umgekehrt.
• Sicherheitsgrenze: Die Control Plane hält die mächtigsten Berechtigungen (sie provisioniert Infrastruktur). Sie von Workloads zu isolieren verkleinert die Angriffsfläche.

Im Interview-Diagramm heißt das: oben ein Management-Cluster mit Portal, GitOps und Policy, darunter mehrere Workload-Cluster, verbunden über deklarative Konfiguration (Git) statt über direkte imperative Zugriffe. Wie die Workload-Cluster geschnitten werden — pro Umgebung, pro Compliance-Zone, pro Region — ist dann ein eigener Deep Dive (Lektion 10).

Trade-offs explizit machen — das eigentliche Bewertungskriterium

Plattform-Design hat keine richtigen Antworten, nur passende. Was Interviewer hören wollen, ist das Muster Optionen → Kriterien → Entscheidung im Kontext. Die wiederkehrenden Entscheidungsachsen:

Entscheidung	Spannungsfeld
Shared Cluster vs. Cluster pro Team	Kosten und Betriebsaufwand vs. Isolation
Ein Konfigurations-Repo vs. Repo pro Team	zentrale Kontrolle vs. Team-Autonomie
Portal kaufen/adoptieren vs. selbst bauen	Time-to-Value vs. Passgenauigkeit (Lektion 11)
Harte Policies vs. weiche Defaults	Compliance-Garantie vs. Entwickler-Reibung

Eine starke Interview-Formulierung klingt so: „Bei 100 Teams ohne regulierte Workloads würde ich einen Shared Cluster pro Umgebung mit Namespace-Isolation wählen — Quotas und NetworkPolicies als Guardrails — weil dedizierte Cluster den Betriebsaufwand vervielfachen. Sobald PCI-Workloads dazukommen, bekommen die einen eigenen Cluster.” Kontext, Kriterium, Entscheidung, Grenze der Entscheidung — vier Elemente in zwei Sätzen.

Eine Faustregel für die Sorgfalt: Je schwerer reversibel eine Entscheidung ist (Tenancy-Modell, Cloud-Wahl), desto mehr Zeit verdient sie. Leicht umkehrbare Entscheidungen (ein Dashboard-Tool) entscheidest du schnell und korrigierst notfalls — diese Unterscheidung anzusprechen wirkt im Interview stark, und Lektion 12 zeigt, wie du die schweren Fälle als ADR dokumentierst.

Praxis: ein Design-Interview gegen die Uhr

Spiele das folgende Szenario allein durch, mit Timer und Whiteboard oder Papier — die Zeitnot ist Teil der Übung:

Aufgabe: „Entwirf eine IDP für einen Versandhändler: 50 Entwicklungsteams, ~300 Services, AWS, keine regulierten Workloads, Hauptschmerz: neue Services brauchen 4 Wochen bis Produktion.”

• Minuten 0–8: Schreibe fünf Scope-Fragen auf und beantworte sie selbst plausibel.
• Minuten 8–15: Liste funktionale Anforderungen, markiere zwei als MVP. Notiere drei NFRs mit konkreten Zielwerten.
• Minuten 15–30: Zeichne die High-Level-Architektur mit Control/Data-Plane-Trennung. Jede Box braucht einen Zweck — Boxen ohne begründeten Zweck streichst du.
• Minuten 30–40: Wähle einen Deep Dive (z. B. Tenancy) und schreibe die Entscheidung im Vier-Elemente-Format: Kontext, Kriterium, Entscheidung, Grenze.
• Minuten 40–45: Formuliere zwei Risiken deines Designs und je eine Gegenmaßnahme.

Wiederhole die Übung mit verändertem Kontext (8 Teams statt 50; oder: PCI-Pflicht) und beobachte, welche Entscheidungen kippen — genau dieses „Design folgt Kontext” ist die Kernkompetenz.

Typische Stolperfallen

Lösung vor Anforderung. Wer in Minute zwei „Kubernetes plus Backstage” sagt, hat die Aufgabe in „rechtfertige meinen Lieblings-Stack” umdefiniert. Erst Scope, dann Tools.

NFRs vergessen. Ein Design ohne Verfügbarkeits-, Sicherheits- und Kostenbetrachtung ist eine Skizze, kein Design — und Blast Radius ist die Plattform-NFR schlechthin.

Über-Dimensionierung als Fleißbeweis. Multi-Region-Active-Active für einen nationalen Händler ohne entsprechende Anforderung zeigt nicht Können, sondern fehlendes Kostenbewusstsein.

Trade-offs verschweigen. Jede Entscheidung ohne genannte Alternative wirkt wie Auswendiggelerntes. Die Formel „Ich wähle X wegen Y; bei Kontext Z würde ich umschwenken” rettet fast jede Antwort.

Interview-Vorbereitung

Wenn die Design-Aufgabe kommt, ist deine Antwortstruktur das halbe Ergebnis: Scope-Fragen stellen → FR/NFR trennen und priorisieren → Größenordnungen überschlagen → Architektur mit Control/Data-Plane-Trennung zeichnen → Deep Dives mit Optionen und Kriterien. Sage die Struktur ruhig explizit an („Ich kläre erst den Scope, dann…”) — das nimmt Druck raus und zeigt Methode.

Rechne mit diesen Follow-ups:

• „Warum trennst du Management- und Workload-Cluster?” — Blast Radius, unabhängige Upgrades, Sicherheitsgrenze für die privilegierte Provisioning-Logik.
• „Was passiert, wenn deine Control Plane ausfällt?” — Workloads laufen weiter; Deployments und Provisioning pausieren. Wichtig: das ist ein bewusst designter degradierter Modus.
• „Wie würde sich dein Design bei 10× mehr Teams ändern?” — Tenancy-Schnitt überdenken (mehr Workload-Cluster, Fleet-Management), Self-Service-Anteil erhöhen, organisatorisch: Plattform selbst in Produkt-Teams aufteilen.
• „Welche Entscheidung in deinem Design ist am schwersten rückgängig zu machen?” — Ehrlich benennen (meist Tenancy-Modell oder Cloud-Bindung) und sagen, dass genau diese ein ADR und die meiste Sorgfalt verdient.

Zusammenfassung

Plattform-System-Design folgt sechs Schritten: Scope → funktionale Anforderungen → NFRs (inklusive Blast Radius) → Größenordnungen → High-Level-Architektur → Deep Dives. Das architektonische Grundmuster ist die Trennung von Control Plane (Portal, GitOps, Policy, Provisioning) und Data Plane (Team-Workloads). Bewertet wird nicht die Tool-Wahl, sondern ob du Entscheidungen als Trade-offs im Kontext begründest — und die Reversibilität einer Entscheidung bestimmt, wie viel Sorgfalt sie verdient.

Schritt 1 und 2 setzen voraus, dass du die Bedürfnisse deiner Nutzer kennst. Wie du sie systematisch erhebst, zeigt die nächste Lektion: Developer Journey Mapping.