System Design: Internal Developer Platform

“Design an Internal Developer Platform” — so eine Frage im System-Design-Interview klingt erstmal zu offen. Bevor du anfängst zu skizzieren, sollte die erste Reaktion eine Gegenfrage sein: “Für welche Organisation? Wie viele Teams? Was ist der aktuelle Pain Point?”

Damit zeigst du, dass eine IDP kein universelles Template hat. Die Antworten verändern das Design fundamental: zehn Teams mit einem gemeinsamen Tech-Stack brauchen Namespace-Isolation und ein paar gute Templates. Hundert Teams mit Compliance-Anforderungen brauchen Cluster-Trennung, Policy-Enforcement und ein dediziertes Platform-Produkt-Team. Ein Brownfield mit fünf Jahren gewachsener Jenkins-Landschaft braucht vor allem eine Migrations-Story — Greenfield-Architekturen gibt es im echten Leben selten.

Die fünf Schichten, die fast jede IDP braucht

Service Catalog — ein zentraler Ort, wo Teams ihre Services definieren, dokumentieren und sichtbar machen. Backstage ist der de-facto-Standard. Wichtig: der Catalog hat nur Mehrwert, wenn er aktuell ist. Automatische Discovery über Entity-Provider aus dem Git-Provider und Staleness-Monitoring sind kein Luxus, sondern Voraussetzung — ein Catalog, dem niemand traut, ist schlimmer als keiner.

Self-Service Infrastructure — Entwickler können Ressourcen anfordern (Datenbanken, Queues, Buckets) ohne Ticket. Crossplane Compositions oder Terraform-basierte Automation bilden die API: der Entwickler committet ein zehnzeiliges Claim-Objekt, dahinter provisioniert die Plattform eine RDS-Instanz mit Backups, Verschlüsselung und den richtigen Tags. Das Interface ist simpel, die Komplexität bleibt Plattform-Zuständigkeit.

Deployment Pipeline — ein standardisierter Weg von Commit zu Production. Ob GitHub Actions plus ArgoCD, Tekton plus Flux, oder etwas anderes — entscheidend ist das gemeinsame Pattern: CI baut und pusht, GitOps synct deklarativ in den Cluster. Verschiedene Patterns für verschiedene Teams sind ein langsames, aber sicheres Drift-Risiko.

Observability — Metriken, Logs, Traces für jeden neuen Service automatisch verfügbar. Prometheus-Scraping per ServiceMonitor aus dem Template, Logging per Default, OTel-Auto-Instrumentation. Kein manuelles Setup, kein Ticket ans Monitoring-Team.

Security Guardrails — Admission-Policies (Kyverno, OPA), Secret-Management (Vault, External Secrets), Image-Scanning, RBAC-Templates. Vorkonfiguriert im Golden Path, nicht als optionale Add-ons, die Teams aktivieren müssten.

Wo der Deep Dive hingeht — und wie du Punkte sammelst

Im Interview wirst du nicht alle fünf Schichten vertiefen. Wähle eine und kündige das an: “Ich würde Multi-Tenancy vertiefen, sag mir, wenn dich ein anderer Bereich mehr interessiert.”

Multi-Tenancy ist der ergiebigste Kandidat, weil er einen sauberen Trade-off-Dreiklang hat: Namespace-Isolation (billig, schwächste Grenzen — Quotas, NetworkPolicies und RBAC müssen stimmen), vCluster (eigene API pro Team, CRD-Freiheit, aber keine harte Security-Grenze), dedizierte Cluster (echte Isolation, höchste Kosten und Betriebslast). Die starke Antwort wählt nicht eine Option, sondern ordnet zu: Namespaces als Default, vCluster für Teams mit Operator-Bedarf, eigene Cluster nur für regulatorisch getrennte Workloads.

Genauso wichtig wie die Architektur: Failure-Modes proaktiv ansprechen, bevor die Frage kommt. Was passiert, wenn ArgoCD ausfällt? (Laufende Workloads laufen weiter, nur Deployments stoppen — das Argument musst du parat haben.) Was, wenn die zentrale Registry down ist? (Pull-through-Cache, imagePullPolicy und bereits gepullte Images auf den Nodes.) Wer Blast-Radius-Fragen selbst aufwirft, signalisiert Betriebserfahrung.

Und die Adoption-Frage nicht überspringen: die beste Plattform scheitert, wenn niemand sie nutzt. Pilot-Team auswählen, dessen größten Pain Point zuerst lösen, Time-to-First-Deploy messen, dann ausrollen. “Big Bang für fünfzig Teams” ist in dieser Frage immer die falsche Antwort.

Wenn nach Priorisierung gefragt wird, hilft eine klare MVP-Logik: zuerst die Schichten, die den größten gemessenen Schmerz adressieren — in den meisten Organisationen sind das Deployment-Pipeline und Observability, weil dort täglich Zeit verloren geht. Der Service Catalog wirkt verlockend als Startpunkt, ist aber gefährlich: ein Portal ohne dahinterliegende Self-Service-Fähigkeiten ist eine hübsche Liste von Links, und genau so werden gescheiterte Backstage-Einführungen beschrieben. Erst die Capability, dann die Tür davor.

Das Mental Model, das den Unterschied macht

Die wichtigste Aussage für ein überzeugendes Gespräch: eine IDP ist kein einmaliges Bauprojekt. Sie ist ein Produkt — mit Backlog, Nutzerfeedback, Release-Zyklen und messbarer Adoption. Das Platform-Team ist das Produkt-Team für die interne Entwicklerinfrastruktur. Konkret heißt das auch: nicht jede Capability selbst bauen. Die Build-vs-Buy-Abwägung (Backstage selbst betreiben oder einen kommerziellen Portal-Anbieter nutzen?) gehört in jede gute Antwort.

Wer so argumentiert, hebt sich von Kandidaten ab, die fünf Tool-Logos auf ein Whiteboard malen. Wie du die 45 Minuten strukturierst, steht in der Interview-Vorbereitung; weitere Cases zum Üben findest du im Lernpfad System Design Cases.