Checkliste und häufige Fallstricke

Lernziele

Nach dieser Lektion hast du eine konkrete Checkliste für Platform-Design-Interviews: was in jeder Phase abgehakt sein muss, welche Non-Functional Requirements du nie vergessen darfst und an welchen Fehlern auch gut vorbereitete Kandidaten scheitern. Du lernst außerdem eine Schlusstechnik, mit der du in den letzten fünf Minuten vergessene Punkte noch einsammelst.

Die Checkliste vor dem ersten Strich

Das Framework aus Lektion 1 sagt dir, wann du was tust — die Checkliste sagt dir, was vollständig bedeutet. Vor dem ersten Strich am Whiteboard müssen drei Dinge stehen:

Requirements geklärt, bevor du zeichnest. Nicht irgendwelche Fragen, sondern die, deren Antwort dein Design ändern würde. „Wie viele Teams?” ist gut, weil 5 Teams ein anderes Design ergeben als 500. „Welche Git-Plattform?” ist meist egal. Ein Selbsttest: Wenn du nicht sagen kannst, was du bei Antwort A anders machen würdest als bei Antwort B, ist die Frage Füllmaterial — und Interviewer erkennen Füllmaterial.

Funktionale und nicht-funktionale Anforderungen getrennt. Funktional: Was muss die Plattform können (Self-Service-Namespaces, automatisierte Deployments, Secrets-Zugriff)? Non-functional: Wie gut muss sie es tun — Availability (Was passiert, wenn die Plattform selbst ausfällt? Können Teams dann noch deployen?), Scalability (Funktioniert das Design auch bei 3× mehr Teams?), Security (Tenant-Isolation, Least Privilege, Audit) und Cost (Was kostet der Betrieb, und wer bezahlt?). Die NFRs sind der Punkt, an dem mittelmäßige von starken Antworten abzweigen — fast jeder nennt Features, kaum jemand spricht unaufgefordert über Kosten.

Erfolgskriterien benannt. Eine Plattform ist ein Produkt. Sag früh: „Erfolg messe ich an Adoption und an DORA-Metriken wie Deployment Frequency und Lead Time.” Das verankert dein Design an einem Ziel und gibt dir später ein Argument für Priorisierungen.

Während des Designs: Fluss, Zustand, Betrieb

Drei Prüffragen, die du dir während der Architekturphase immer wieder stellst:

Erkläre ich den Datenfluss, nicht nur Boxen? Ein Diagramm mit zehn Komponenten ohne erzählten Ablauf ist wertlos. Geh mindestens einen Pfad komplett durch — vom auslösenden Ereignis („Entwickler merged einen PR”) bis zum Endzustand („neue Version läuft, Alert-Routing ist aktualisiert”). Wenn du dabei stockst, hast du eine Lücke gefunden, bevor der Interviewer sie findet.

Wo liegt der Zustand? Jedes System hat irgendwo State: Git-Repos, Datenbanken, etcd, ein Secrets-Backend. Markiere diese Stellen bewusst, denn dort entstehen die harten Fragen — Backup, Konsistenz, was bei Verlust passiert. Wer Stateful- von Stateless-Komponenten nicht unterscheidet, kann später keine sinnvolle Failure-Analyse liefern.

Ist Betrieb mitgedacht? Monitoring und Alerting gehören in jedes Platform-Design, unaufgefordert. Ein Satz reicht oft: „Jede Plattform-Komponente exportiert Metriken, wir alerten auf Symptome wie fehlgeschlagene Syncs, nicht auf Ursachen.” Ebenso Upgrades: Eine Plattform, die niemand aktualisieren kann, ohne 50 Teams zu stören, ist ein Design-Fehler — sprich Rollout-Strategien für die Plattform selbst an.

Die häufigsten Fehler — und ihre Gegenmittel

Sofort in Details springen. Du wirst nach einer Plattform gefragt und redest nach drei Minuten über Cilium-Konfiguration. Gegenmittel: Erst das komplette grobe Bild, dann explizit ankündigen: „Jetzt würde ich vertiefen — wo soll ich hin?” Detailtiefe ist nur dann ein Plus, wenn sie an der richtigen Stelle sitzt.

Nur eine Lösung präsentieren. Du nennst Argo CD, und auf „Warum nicht Flux?” folgt Schweigen. Gegenmittel: Trainiere dir an, jede größere Entscheidung mit einer Alternative auszusprechen — „Ich nehme X; Y wäre die Alternative, wenn Bedingung Z gilt.” Das kostet zehn Sekunden und verwandelt eine angreifbare Behauptung in eine abgewogene Entscheidung.

„Kubernetes” als Antwort auf alles. Auf die Frage nach Build-Infrastruktur, Datenhaltung oder Entwickler-Onboarding reflexhaft „das läuft auf Kubernetes” zu sagen, beantwortet nichts — Kubernetes ist Laufzeitumgebung, nicht Architektur. Gegenmittel: Beschreibe erst die Fähigkeit (Warteschlange, Workflow-Engine, Cache), dann die Umsetzung. Manchmal ist die ehrliche Antwort sogar ein Managed Service statt eines weiteren Operators im Cluster.

Schweigend zeichnen. Zwei Minuten Stille, während du malst, sind für den Interviewer zwei Minuten ohne bewertbares Signal. Gegenmittel: Denken hörbar machen — dazu ausführlich Lektion 3.

Der Abschluss-Sweep: die letzten fünf Minuten

Eine Technik, die kaum jemand nutzt: Reserviere die letzten fünf Minuten für einen systematischen Sweep über vier Fragen, die du laut durchgehst.

1. „Was fällt aus?” — Benenne die zwei kritischsten Komponenten und das Verhalten bei Ausfall. Gut ist, wenn die Plattform degradiert statt blockiert: Laufende Apps laufen weiter, auch wenn das Portal down ist.
2. „Was passiert bei 10×?” — Zehnmal mehr Teams, Builds, Requests: Welche Komponente kippt zuerst? Du brauchst keine fertige Lösung, nur den identifizierten Engpass.
3. „Was habe ich bewusst weggelassen?” — Scope-Entscheidungen explizit machen: „Multi-Region habe ich ausgeklammert, weil die Anforderung Single-Region war.” Das verwandelt Lücken in Entscheidungen.
4. „Wie sieht Phase 1 aus?” — Ein realistischer erster Schritt: Pilot mit zwei Teams, dann Iteration. Big-Bang-Rollouts sind in Platform-Kontexten fast immer die falsche Antwort.

Dieser Sweep fängt vergessene Punkte ein und hinterlässt einen starken letzten Eindruck — der Interviewer schreibt seine Notizen direkt nach dem Gespräch.

Praxis

Erstelle aus dieser Lektion deine persönliche Einseiten-Checkliste (15 Minuten) und teste sie dann an einem Mini-Case (30 Minuten): „Designe eine zentrale Container-Registry für 40 Teams mit Image-Signing-Pflicht.” Diese fünf Punkte müssen vorkommen:

1. Drei Klärungsfragen, zu denen du jeweils sagen kannst, wie die Antwort dein Design ändert.
2. Funktionale und nicht-funktionale Anforderungen als getrennte, laut vorgelesene Listen.
3. Ein komplett durcherzählter Datenfluss (Push → Scan → Signierung → Pull im Cluster).
4. Mindestens zwei Entscheidungen im Format „X, Alternative Y falls Z”.
5. Der vollständige Abschluss-Sweep mit allen vier Fragen.

Hake während der Übung auf deiner Checkliste ab. Alles, was am Ende nicht abgehakt ist, ist dein Lernpunkt für den nächsten Durchlauf.

Typische Stolperfallen

Die Checkliste laut aufsagen. „Jetzt komme ich zu Punkt 4 meiner Checkliste” wirkt mechanisch. Die Checkliste ist dein internes Werkzeug — nach drei, vier Übungsdurchläufen läuft sie unsichtbar im Hintergrund.

NFRs nennen und dann ignorieren. Wer in Minute 5 „Availability ist wichtig” sagt und danach nie wieder über Ausfälle spricht, hat es schlimmer gemacht als wer schweigt — er hat gezeigt, dass er weiß, was fehlt, und es trotzdem weglässt. Jede genannte NFR braucht später mindestens einen Satz Umsetzung.

Kosten komplett auslassen. Gerade bei Plattform-Themen (Observability-Datenmengen, CI-Compute, Cluster-Anzahl) ist Cost oft die dominante Design-Kraft. Ein Satz wie „Logs-Retention ist hier der größte Kostenhebel, deshalb 7 Tage hot, danach Object Storage” hebt dich sofort ab.

Vollständigkeit mit Qualität verwechseln. Alle Punkte oberflächlich abzuhaken schlägt keinen fokussierten Deep Dive. Die Checkliste sichert das Minimum ab — überzeugen tust du in der Tiefe.

Interview-Vorbereitung

Deine Kernbotschaft: Vollständigkeit ist trainierbar — Requirements vor dem Zeichnen, NFRs explizit (Availability, Scalability, Security, Cost), Datenfluss statt Boxen, Betrieb mitgedacht, und ein Abschluss-Sweep über Ausfälle, Skalierung, Scope und Rollout.

Rechne mit diesen Follow-ups:

• „Welche Punkte prüfst du vor dem Abschluss eines Design-Interviews?” — Den Vier-Fragen-Sweep: Was fällt aus, was passiert bei 10×, was habe ich bewusst ausgeklammert, wie sieht Phase 1 aus.
• „Nenne drei typische Fallstricke.” — Details vor dem Gesamtbild, nur eine Lösung ohne Alternative, NFRs nennen aber nicht umsetzen.
• „Was vergessen Kandidaten am häufigsten?” — Kosten und das Betriebsmodell der Plattform selbst (Upgrades, Monitoring der Plattform-Komponenten); dagegen hilft ein fester Slot im Abschluss-Sweep.
• „Woran erkennst du eine gute Klärungsfrage?” — Die Antwort verändert das Design; wenn beide Antworten zum selben Design führen, war die Frage überflüssig.

Zusammenfassung

Die Checkliste ergänzt das Framework um Vollständigkeit: vor dem Zeichnen Requirements, NFRs und Erfolgskriterien; während des Designs Datenfluss, State-Verortung und Betrieb; gegen Ende der Vier-Fragen-Sweep. Die vier klassischen Fehler — Details zu früh, keine Alternativen, Kubernetes-Reflex, stilles Zeichnen — haben jeweils ein einfaches Gegenmittel, das du in Übungsläufen automatisierst. Der letzte Baustein der Methodik fehlt noch: Wie du währenddessen redest, den Interviewer einbindest und mit Einwänden umgehst — darum geht es in der nächsten Lektion.