Hinweis. Dieser Artikel basiert ausschließlich auf öffentlichen Kommunikationen von Netflix — ihrem Tech-Blog, Konferenz-Talks, Open-Source-Repositories und externen Case Studies. Es ist kein offizielles Architektur-Dokument von Netflix. Wir modellieren das, was wir öffentlich wissen, um zu zeigen, wie ein komplexer Stack mit dem C4-Modell lesbar gemacht werden kann. Wenn Details inferiert sind statt von Netflix bestätigt, sagen wir das.

Anatomie eines Plays: Netflix in C4 mit Archyl modellieren

Wenn du bei Netflix Play drückst, arbeiten rund fünfzig Services in unter 200 Millisekunden zusammen, damit die Bytes auf deinen Fernseher fließen.

Authentifizierung, Profil-Resolution, Eligibility-Check, Watch-State-Lookup, Manifest-Generierung, DRM-Lizenz-Ausstellung, Ad Decisioning (seit 2023), CDN-Routing, Edge-Cache-Hit, Bitrate-Negotiation, Packet Pacing — all das, bevor Frame Null deinen Bildschirm trifft.

Netflix betreibt über tausend Microservices. Ihr Tech-Blog erwähnt beiläufig "the membership platform", als wäre es eine einzige Sache — es sind zwölf Services. "The video pipeline" sind Dutzende von Microservices, orchestriert über drei architektonische Layer. "Open Connect" ist eine globale Flotte von zehntausend FreeBSD-Appliances, eingebettet in ISP-Netzwerke.

Wie versteht man so einen Stack? Man versteht ihn nicht — nicht auf einmal. Genau das ist das Problem, das das C4-Modell erfunden wurde, um zu lösen.

In diesem Post modellieren wir Netflix' Architektur über die vier C4-Ebenen — System Context, Container, Component und Code — und zeigen, wie Archyl einen Stack dieser Größenordnung nicht nur dokumentierbar, sondern lesbar macht.

Wir werden nicht jeden Service abdecken. Niemand könnte. Wir folgen einer einzigen Nutzeraktion — Play drücken — und schauen zu, wie sie die Layer durchquert.

Ebene 1 — System Context: zehn Dinge, nicht tausend

Auf der System-Context-Ebene ist Netflix nicht tausend Microservices. Es sind zehn Systeme.

Wenn man Netflix' öffentliche Kommunikationen der letzten fünf Jahre anschaut, treten zehn distinkte Systeme konsistent hervor:

1. Member Experience — Signup, Billing, Account, Profile, Plan-Management
2. Content Discovery — Search, Recommendations, Browse, Ranking
3. Streaming Platform — Playback, Manifests, DRM, QoE
4. Open Connect — das proprietäre globale CDN
5. Studio Engineering — Tools von Pre- bis Post-Production
6. Content Engineering — Katalog, Metadaten, Taxonomie
7. Data Platform — Kafka, Flink, Iceberg, Atlas, Mantis
8. Cloud Platform — Spinnaker, Titus, Eureka, die föderierte Developer-Konsole
9. Security — Perimeter, Secrets, Threat Detection
10. Ads Platform — 2023 mit dem Ad-Supported-Tier hinzugefügt

Drumherum: Members auf Hunderten von Device-Typen, ISPs, die Open-Connect-Appliances hosten, AWS als zugrundeliegende Cloud, DRM-Partner (Widevine, PlayReady, FairPlay), Payment-Prozessoren und Partner-Biller (App Store, Google Play, Telco-Bundles), Content-Studios auf der Lieferantenseite.

Das war's. Zehn Systeme, sechs Kategorien externer Akteure. Alles andere ist Detail.

Das ist das Geschenk von Ebene 1: Im System Context musst du nicht wissen, dass Membership zwölf Microservices sind. Du musst wissen, dass es existiert, dass es mit Billing spricht, und dass irgendwann ein ISP deine Bytes hostet. Das Diagramm ist ein Gesprächs-Starter, kein Inventar.

ADR-001 · Open Connect bauen, nicht für ein CDN bezahlen

Status · Accepted (2011, 2026 immer noch aktiv)

Kontext · Streaming-Traffic wuchs exponentiell. Kommerzielle CDNs (Akamai, Limelight, Level 3) konnten Per-Frame-Qualität in Netflix-Skalierung nicht garantieren, und die Kostenkurve war untragbar.

Entscheidung · Ein proprietäres CDN bauen. Appliances in ISP-Netzwerke einbetten. Über Nacht prefetchen, wenn die Netzwerke idle sind. Auf FreeBSD + NGINX laufen mit NVMe + HDD Storage.

Konsequenzen · Etwa 95% des Netflix-Video-Traffics wird heute direkt von Open Connect serviert. Das CDN hörte auf, eine Kostenposition zu sein, und wurde zu einem strategischen Burggraben. Das Ebene-1-Diagramm hat Open Connect dort, wo jeder andere Streaming-Dienst Akamai hat.

Die Entscheidung, Open Connect zu bauen, ist die einzige architektonische Entscheidung, die Netflix' Ebene-1-Diagramm am stärksten formt. Ohne sie hätte das Diagramm eine riesige Akamai-Box, wo heute das gesamte CDN sitzt.

In Archyl verdient sich ein ADR so seinen Platz: Es erklärt, warum das Diagramm so aussieht, wie es aussieht.

Ebene 2 — Container: Zoom in die Streaming Platform

Du drückst Play, und dein Client — sagen wir ein Smart-TV — trifft die Streaming Platform. Lass uns die Box öffnen.

In der Streaming Platform offenbaren öffentliche Quellen mindestens diese Container:

• Playback API — der Eingangspunkt. Validiert die Session, prüft Concurrent-Stream-Limits, entscheidet über Bitrate-Ladder-Eligibility.
• Manifest Service (Cadmium / Akira im internen Netflix-Vokabular) — generiert das Per-Session-HLS- oder DASH-Manifest, signiert es.
• License Service — Handshake mit dem DRM des Devices (Widevine für Android/Chrome, PlayReady für Edge/Xbox, FairPlay für Apple).
• MSL Gateway — Netflix' proprietärer Message Security Layer, das Protokoll, das Clients sprechen, bevor HTTPS innerhalb der Plattform terminiert.
• FTL (Fast Track Live) — die Live-Streaming-Pipeline.
• EVCache — eine 22 000-Instanz-Memcached-Flotte mit 14,3 PB Working Set, die heiße Session- und Metadata-Reads frontet.
• Cassandra-Cluster — Viewing State, Watch History, dauerhafte Session-Daten.

Ein typischer Play berührt Playback API → Manifest Service → License Service parallel, alle aus EVCache serviert, wenn warm, und aus Cassandra, wenn nicht. Die Manifest-URL zeigt auf eine Open Connect Appliance — und von dort spricht dein TV mit einem Server, der buchstäblich im Datacenter deines ISPs sein könnte, Millisekunden entfernt.

Der Tech-Stack auf dieser Ebene: Java mit Spring Boot, gRPC für Inter-Service-Calls, Kafka für Events, GraphQL Federation für Client-APIs seit der Falcor → GraphQL-Migration 2022.

ADR-002 · Cassandra als Default-Datastore

Status · Accepted (2011, immer noch aktiv für die meisten Stateful Workloads)

Kontext · Der Datacenter-Ausfall von Netflix 2008 bewies, dass eine einzelne Primary-Database ein Single Point of Business Failure ist. Multi-DC Eventual Consistency, lineare Schreib-Skalierung, kein SPOF wurden zu den neuen Anforderungen.

Entscheidung · Cassandra als Default-Datastore für neue Services adoptieren. Eventual Consistency auf der Datenebene akzeptieren. EVCache obendrauf bauen, um den Hot Read Path abzudecken.

Konsequenzen · Die meisten Stateful Services sind Cassandra-backed. Multi-Region Active-Active wird natürlich. Für Workloads, die globale SQL-Transaktionen brauchen (Membership Pricing, Redemption Codes), wurde 2020 CockroachDB hinzugefügt — aber Cassandra besitzt immer noch die dauerhaften Nutzerdaten.

Zwei ADRs später beginnt das Diagramm Sinn zu ergeben. Container-Entscheidungen folgen aus Systemebene-Entscheidungen, die aus Business-Constraints folgen.

Ebene 3 — Component: in der Cosmos-Video-Pipeline

Encoding passiert nicht zur Play-Zeit. Es passiert Monate vorher, wenn ein Titel ingeriert wird. Aber es ist ein wunderschönes Ebene-3-Beispiel — ein Ort, wo Netflix genug publiziert hat, dass wir das Innere eines ihrer Container kartieren können.

Cosmos ist die Plattform, die Reloaded abgelöst hat, Netflix' vorherige Video-Pipeline. Die Migration wurde im September 2023 nach Jahren der Arbeit abgeschlossen. Jeder Cosmos-Microservice folgt einem Drei-Layer-Muster:

• Optimus — der API-Layer, extern exponiert
• Plato — der Workflow-Orchestrierungs-Layer
• Stratum — der serverlose Compute-Layer

Ein Titel, der durch Encoding läuft, durchquert eine Kette von Komponenten, jede ein Cosmos-Microservice:

1. VIS — Video Inspection Service. Sondiert das Quell-Asset.
2. CAS — Complexity Analysis Service. Bewertet, wie schwer der Inhalt zu encodieren ist.
3. LGS — Ladder Generation Service. Entscheidet die Bitrate-Ladder.
4. VES — Video Encoding Service. Eigentliches Encoding, chunkweise parallelisiert.
5. VVS — Video Validation Service. Verifiziert Output-Integrität.
6. VQS — Video Quality Service. Bewertet das Ergebnis mit VMAF, Netflix' open-source perzeptueller Qualitätsmetrik.

So sieht Component-Level C4 aus: nicht "hier ist Code", sondern "hier ist die Kette von business-bedeutsamen Primitiven, jede owned, jede ersetzbar, jede messbar".

ADR-003 · Migration von Reloaded zu Cosmos

Status · Accepted (begonnen ~2018, abgeschlossen September 2023)

Kontext · Reloaded war eine monolithische, sequentielle Video-Pipeline. Als Netflix' Katalog wuchs und die Codec-Komplexität explodierte (HDR, AV1, Per-Shot-Encoding), wurde Reloaded zum Bottleneck — einen neuen Codec hinzuzufügen erforderte den Wiederaufbau der gesamten Pipeline.

Entscheidung · In Chunk-parallele Microservices zerlegen, jeder mit dem Drei-Layer-Optimus/Plato/Stratum-Pattern. Timestone, ein Netflix-internes priority-aware Messaging-System, zur Orchestrierung verwenden.

Konsequenzen · Encoding-Throughput multiplizierte sich. Neue Codecs und Qualitätsexperimente wurden komponierbar, nicht katastrophal. Die Zerlegung schaltete Per-Shot-Encoding frei, was direkt die Bitrate-Effizienz für die Member-Experience verbesserte.

In einem Archyl-Modell reisen ADRs wie diese mit der Architektur. Wenn du 2026 in den Cosmos-Container klickst und sieben Komponenten siehst, siehst du auch die Entscheidung von 2018, die erklärt, warum es sieben sind und nicht eine.

Drei Entscheidungen. Drei Cards in Archyl, jede mit den C4-Elementen verknüpft, die sie formt — Open Connect mit seiner System-Box, Cassandra mit dem Datastore-Container, Cosmos mit den Komponenten, die vor 2018 nicht existierten. Das Diagramm ist die Gegenwart; die ADRs sind das Warum.

Ownership: ein Modell in Verantwortlichkeit verwandeln

Ein C4-Modell ist ein statisches Artefakt, bis du ihm Teams zuordnest.

Netflix kommuniziert öffentlich über seine Gruppen: Member Systems, Studio Engineering, Open Connect (eine eigene Hardware-fokussierte Org), Cloud Platform, Streaming Algorithms, Data Platform, Insight Engineering, Security, Ads Engineering und Personalization Research.

Setze sie auf das C4-Modell:

• Member Systems besitzt Member Experience und die Ads Platform
• Studio Engineering besitzt die Studio + Content Engineering Container
• Open Connect besitzt das gesamte Open-Connect-System von oben bis unten — ihre vertikale Integration Hardware/Software ist berühmt
• Cloud Platform besitzt Spinnaker, Titus, Eureka — das Plattform-Gewebe
• Streaming Algorithms besitzt die Encoding-Komponenten (die Cosmos-Pipeline)
• Data Platform besitzt Kafka, Flink, Iceberg, Atlas, Mantis
• Personalization Research besitzt Reco-Modelle, Search, Ranking

Diese Zuordnung ist keine Dekoration. Sie ist das Substrat für alles, was danach kommt.

Sobald ein System, Container oder Komponente einen Team-Eigentümer hat, wird Drift-Detection verantwortlich: Wenn ein neuer Service in Commits auftaucht und nicht im Diagramm ist, wird ein spezifisches Team gefragt. Wenn eine Konformitätsregel verletzt wird, gibt es einen Namen in einer Inbox. Wenn ein ADR geschrieben werden muss, kollabiert die Mehrdeutigkeit.

In Archyl ist die Ownership Map der Moment, in dem aus einem Doku-Tool ein Governance-Tool wird.

Drift, Konformität und der wöchentliche Digest

Ein Modell dieser Größe wird driften. Neue Services landen. Alte werden ausgemustert. Stacks ändern sich — Falcor → GraphQL Federation, Reloaded → Cosmos, Hystrix → Maintenance.

Archyl berechnet einen Drift-Score wöchentlich: die Lücke zwischen dem dokumentierten C4-Modell und dem, was aktuell im Code ist. Konformitätsregeln fügen den Policy-Layer hinzu — "jeder Container braucht ein Eigentümer-Team", "kein Cross-Database-Zugriff", "jede ADR-markierte Technologie muss im Radar sein".

Für Netflix ist das Drift-Detection in der Größenordnung von tausend Services. Aber die Regeln sind dieselben wie für zehn.

Und der Architektur-Team-Digest, den wir letzte Woche ausgeliefert haben, würde in einem Netflix-ähnlichen Setup heißen:

• Member Systems' Montag-Digest deckt ihre zwölf Membership-Microservices ab
• Open Connects Digest deckt die OCAs und den Control Plane ab
• Streaming Algorithms' Digest deckt Cosmos und die Encoding-Komponenten ab
• Jeder Digest gescoped auf den Perimeter, den sein Team besitzt, in seiner eigenen Zeitzone

Gleiche Oberfläche. Verschiedene Scopes. Das ist die Symmetrie, die C4 + Ownership freischalten.

Du brauchst keine tausend Services

Du bist nicht Netflix. Die meisten Engineering-Organisationen sind es nicht.

Aber die Lektion skaliert auch nach unten. Die Disziplin, Context von Container von Component zu trennen, das ADR zu schreiben, das das Diagramm erklärt, jeder Box Ownership zuzuordnen — diese Disziplin ist es, die einen Stack von fünfzig Services davon abhält, sich wie tausend anzufühlen.

C4 + ADRs + Ownership + Drift + Konformität ist das, was Archyl dir out of the box gibt. Das Netflix-Beispiel ist nur der größte plausible Stress-Test des Modells.

Öffne deine eigene Architektur. Skizziere zehn Systeme. Wähle das, das am meisten weh tut, und zoome in seine Container. Schreibe drei ADRs, die erklären, warum die Entscheidungen so aussehen. Ordne jedem Container ein Team zu.

Du wirst weiter sein als die meisten Engineering-Organisationen in einem Jahr.

Willst du deine eigene Architektur in C4 modellieren? Starte mit Archyl. Lies auch warum ADRs und C4 besser zusammen funktionieren oder wie Architecture Change Requests Pull-Request-Disziplin in dein C4-Modell bringen.