Avertissement. Cet article s'appuie uniquement sur les communications publiques de Netflix — leur tech blog, leurs présentations en conférence, leurs dépôts open source et des études de cas externes. Ce n'est pas un document d'architecture officiel Netflix. On modélise ce qu'on sait publiquement pour illustrer comment une stack complexe peut être rendue lisible avec le modèle C4. Quand certains détails sont déduits plutôt qu'affirmés par Netflix, on le précise.
Anatomie d'un Play : modéliser Netflix en C4 avec Archyl
Quand vous appuyez sur Play sur Netflix, environ cinquante services collaborent en moins de 200 millisecondes pour faire couler les bytes vers votre téléviseur.
Authentification, résolution du profil, vérification d'éligibilité, lecture de l'état de visionnage, génération du manifest, émission de la licence DRM, decisioning publicitaire (depuis 2023), routage CDN, hit cache edge, négociation du bitrate, paquetage — tout ça, avant que la première frame ne s'affiche.
Netflix opère plus d'un millier de microservices. Leur tech blog mentionne désinvolture « la membership platform » comme s'il s'agissait d'une seule chose — c'est douze services. « Le video pipeline » est des dizaines de microservices orchestrés sur trois couches architecturales. « Open Connect » est une flotte mondiale de dix mille appliances FreeBSD intégrées dans les réseaux des ISP.
Comment comprend-on une stack pareille ? On ne la comprend pas, pas d'un coup. C'est exactement le problème que le modèle C4 a été inventé pour résoudre.
Dans ce post, on modélise l'architecture de Netflix sur les quatre niveaux C4 — System Context, Container, Component, Code — et on montre comment Archyl rend une stack de cette ampleur non seulement documentable, mais lisible.
On ne couvrira pas chaque service. Personne ne pourrait. On va suivre une seule action utilisateur — appuyer sur Play — et la regarder traverser les couches.
Niveau 1 — System Context : dix choses, pas mille
Au niveau System Context, Netflix n'est pas mille microservices. C'est dix systèmes.
En regardant les communications publiques de Netflix sur les cinq dernières années, dix systèmes distincts émergent de manière cohérente :
- Member Experience — signup, billing, compte, profils, gestion de plan
- Content Discovery — search, recommandations, browse, ranking
- Streaming Platform — playback, manifests, DRM, QoE
- Open Connect — le CDN propriétaire mondial
- Studio Engineering — outils de la pré- à la post-production
- Content Engineering — catalogue, métadonnées, taxonomie
- Data Platform — Kafka, Flink, Iceberg, Atlas, Mantis
- Cloud Platform — Spinnaker, Titus, Eureka, console développeur fédérée
- Security — périmètre, secrets, threat detection
- Ads Platform — ajouté en 2023 avec le tier ad-supported
Autour : les membres sur des centaines de types de devices, les ISPs hébergeant les Open Connect appliances, AWS comme cloud sous-jacent, les partenaires DRM (Widevine, PlayReady, FairPlay), les processeurs de paiement et les billers partenaires (App Store, Google Play, bundles telco), les studios de contenu côté fournisseur.
C'est tout. Dix systèmes, six catégories d'acteurs externes. Tout le reste, c'est du détail.
C'est le cadeau du Niveau 1 : au System Context, on s'en fout que Membership soit douze microservices. On retient qu'il existe, qu'il parle au billing, et qu'un ISP héberge finalement vos bytes.
ADR-001 · Construire Open Connect, ne pas payer un CDN
Statut · Accepted (2011, toujours actif en 2026)
Contexte · Le trafic de streaming croissait exponentiellement. Les CDN commerciaux (Akamai, Limelight, Level 3) ne pouvaient pas garantir la qualité par-frame à l'échelle Netflix, et la courbe de coûts était insoutenable.
Décision · Construire un CDN propriétaire. Embarquer des appliances dans les réseaux des ISP. Préfetcher la nuit, quand les réseaux sont au repos. Tourner sur FreeBSD + NGINX avec stockage NVMe + HDD.
Conséquences · Environ 95 % du trafic vidéo Netflix est désormais servi directement par Open Connect. Le CDN a cessé d'être une ligne de coût pour devenir un fossé stratégique. Le diagramme de Niveau 1 a Open Connect là où chaque autre service de streaming a Akamai.
La décision de construire Open Connect est le choix architectural unique qui façonne le plus le diagramme Niveau 1 de Netflix. Sans elle, le diagramme aurait une énorme boîte Akamai là où le CDN entier siège aujourd'hui.
Dans Archyl, c'est comme ça qu'une ADR gagne sa place : elle explique pourquoi le diagramme a la forme qu'il a.
Niveau 2 — Container : zoom sur la Streaming Platform
Vous appuyez sur Play, et votre client — disons une Smart TV — frappe la Streaming Platform. Ouvrons la boîte.
À l'intérieur de Streaming Platform, les sources publiques révèlent au moins ces containers :
- Playback API — le point d'entrée. Valide la session, vérifie les limites de streams concurrents, décide de l'éligibilité au bitrate ladder.
- Manifest Service (Cadmium / Akira dans le vocabulaire interne Netflix) — génère le manifest HLS ou DASH par session, le signe.
- License Service — fait le handshake avec le DRM du device (Widevine pour Android/Chrome, PlayReady pour Edge/Xbox, FairPlay pour Apple).
- MSL Gateway — Message Security Layer, le protocole propriétaire que les clients parlent avant que HTTPS termine à l'intérieur de la plateforme.
- FTL (Fast Track Live) — le pipeline de streaming live.
- EVCache — une flotte Memcached de 22 000 instances avec 14,3 Po de working set, qui front les hot reads de session et de métadonnées.
- Clusters Cassandra — état de visionnage, watch history, données de session durables.
Un play typique touche Playback API → Manifest Service → License Service en parallèle, tous servis depuis EVCache quand chaud et depuis Cassandra sinon. L'URL du manifest pointe vers une Open Connect appliance — et de là, votre TV parle à un serveur qui peut littéralement être à l'intérieur du datacenter de votre ISP, à quelques millisecondes.
La stack technologique à ce niveau : Java avec Spring Boot, gRPC pour les appels inter-services, Kafka pour les events, GraphQL Federation pour les API client depuis la migration Falcor → GraphQL en 2022.
ADR-002 · Cassandra comme datastore par défaut
Statut · Accepted (2011, toujours actif pour la majorité des workloads stateful)
Contexte · La panne datacenter de Netflix en 2008 a prouvé qu'une base de données primaire unique est un single point of business failure. Eventual consistency multi-DC, scale linéaire en écriture, pas de SPOF — sont devenus les nouveaux requirements.
Décision · Adopter Cassandra comme datastore par défaut pour les nouveaux services. Accepter l'eventual consistency au niveau data. Construire EVCache au-dessus pour couvrir le hot read path.
Conséquences · La majorité des services stateful sont Cassandra-backed. Le multi-region active-active devient naturel. Pour les workloads nécessitant des transactions SQL globales (membership pricing, redemption codes), CockroachDB a été ajouté en 2020 — mais Cassandra possède toujours les données utilisateur durables.
Deux ADRs, et le diagramme commence à prendre du sens. Les choix de container découlent des décisions au niveau système, qui découlent des contraintes business.
Niveau 3 — Component : à l'intérieur du pipeline vidéo Cosmos
L'encodage n'a pas lieu au moment du play. Il a lieu des mois plus tôt, quand un titre est ingéré. Mais c'est un magnifique exemple de Niveau 3 — un endroit où Netflix a publié assez pour qu'on puisse cartographier l'intérieur d'un de leurs containers.
Cosmos est la plateforme qui a remplacé Reloaded, le précédent video pipeline Netflix. La migration s'est terminée en septembre 2023 après des années de travail. Chaque microservice Cosmos suit un pattern à trois couches :
- Optimus — la couche API, exposée à l'extérieur
- Plato — la couche d'orchestration de workflow
- Stratum — la couche serverless de compute
Un titre qui traverse l'encodage parcourt une chaîne de composants, chacun étant un microservice Cosmos :
- VIS — Video Inspection Service. Sonde l'asset source.
- CAS — Complexity Analysis Service. Score à quel point le contenu est dur à encoder.
- LGS — Ladder Generation Service. Décide du bitrate ladder.
- VES — Video Encoding Service. Encodage proprement dit, parallélisé par chunks.
- VVS — Video Validation Service. Vérifie l'intégrité de la sortie.
- VQS — Video Quality Service. Score le résultat avec VMAF, la métrique de qualité perceptuelle open source de Netflix.
Voilà à quoi ressemble du Niveau 3 C4 : pas « voici du code », mais « voici la chaîne de primitives métier-significatives, chacune ownée, chacune remplaçable, chacune mesurable ».
ADR-003 · Migrer de Reloaded à Cosmos
Statut · Accepted (démarré ~2018, terminé septembre 2023)
Contexte · Reloaded était un video pipeline monolithique et séquentiel. Quand le catalogue Netflix a grossi et que la complexité des codecs a explosé (HDR, AV1, encodage par-shot), Reloaded est devenu le bottleneck — ajouter un nouveau codec exigeait de reconstruire tout le pipeline.
Décision · Décomposer en microservices chunk-parallel, chacun implémentant le pattern à trois couches Optimus / Plato / Stratum. Utiliser Timestone, un système de messaging Netflix-interne avec gestion de priorité, pour orchestrer.
Conséquences · Le throughput d'encodage a été multiplié. Les nouveaux codecs et expérimentations qualité sont devenus composables, plus catastrophiques. La décomposition a débloqué l'encodage par-shot, qui a directement amélioré l'efficacité bitrate pour l'expérience membre.
Dans un modèle Archyl, des ADRs comme celle-ci voyagent avec l'architecture. Quand vous cliquez dans le container Cosmos en 2026 et voyez sept composants, vous voyez aussi la décision de 2018 qui explique pourquoi c'est sept et pas un.
Trois décisions. Trois cards dans Archyl, chacune liée aux éléments C4 qu'elle façonne — Open Connect à sa boîte système, Cassandra au container datastore, Cosmos aux composants qui n'existaient pas avant 2018. Le diagramme est le présent ; les ADRs sont le pourquoi.
Ownership : transformer un modèle en responsabilité
Un modèle C4 reste un artefact statique tant qu'on ne mappe pas les équipes dessus.
Netflix communique publiquement sur ses groupes : Member Systems, Studio Engineering, Open Connect (une org distincte centrée hardware), Cloud Platform, Streaming Algorithms, Data Platform, Insight Engineering, Security, Ads Engineering, et Personalization Research.
Posez-les sur le modèle C4 :
- Member Systems owne Member Experience et la Ads Platform
- Studio Engineering owne les containers Studio + Content Engineering
- Open Connect owne le système Open Connect entier de haut en bas — leur intégration verticale hardware/software est célèbre
- Cloud Platform owne Spinnaker, Titus, Eureka — le tissu plateforme
- Streaming Algorithms owne les composants d'encodage (le pipeline Cosmos)
- Data Platform owne Kafka, Flink, Iceberg, Atlas, Mantis
- Personalization Research owne les modèles de reco, search, ranking
Ce mapping n'est pas décoratif. C'est le substrat de tout ce qui suit.
Une fois qu'un système, container ou composant a une équipe propriétaire, la détection de drift devient responsable : quand un nouveau service apparaît dans les commits sans être sur le diagramme, une équipe spécifique est interpellée. Quand une règle de conformité est violée, il y a un nom dans une inbox. Quand une ADR doit être écrite, l'ambiguïté s'effondre.
Dans Archyl, la Ownership Map est le moment où un outil de doc devient un outil de gouvernance.
Drift, conformité, et le récap hebdomadaire
Un modèle de cette taille va dériver. De nouveaux services arrivent. Les anciens sont retirés. Les stacks bougent — Falcor → GraphQL Federation, Reloaded → Cosmos, Hystrix → maintenance.
Archyl calcule un score de drift hebdomadaire : l'écart entre le modèle C4 documenté et ce qui est actuellement dans le code. Les règles de conformité ajoutent la couche de policy — « chaque container doit avoir une équipe propriétaire », « pas d'accès cross-database », « chaque techno marquée ADR doit être dans le radar ».
Pour Netflix, c'est de la détection de drift à l'échelle d'un millier de services. Mais les règles sont les mêmes que pour dix.
Et le Récap d'architecture d'équipe qu'on a livré la semaine dernière, dans un setup à la Netflix, voudrait dire :
- Le récap du lundi de Member Systems couvre leurs douze microservices de membership
- Le récap d'Open Connect couvre les OCAs et le control plane
- Le récap de Streaming Algorithms couvre Cosmos et les composants d'encodage
- Chaque récap scopé au périmètre owné par son équipe, dans son fuseau horaire
Même surface. Périmètres différents. C'est la symétrie que C4 + ownership débloquent.
Vous n'avez pas besoin de mille services
Vous n'êtes pas Netflix. La majorité des organisations d'ingénierie ne le sont pas.
Mais la leçon scale aussi vers le bas. La discipline de séparer Context, Container et Component, d'écrire l'ADR qui explique le diagramme, d'attacher l'ownership à chaque boîte — cette discipline est ce qui empêche une stack de cinquante services de donner l'impression d'en avoir mille.
C4 + ADRs + Ownership + Drift + Conformité est ce qu'Archyl vous donne d'office. L'exemple Netflix est juste le plus gros stress-test plausible du modèle.
Ouvrez votre propre architecture. Esquissez dix systèmes. Choisissez celui qui fait le plus mal, zoomez dans ses containers. Écrivez trois ADRs qui expliquent pourquoi les choix ressemblent à ce qu'ils sont. Mappez une équipe à chaque container.
Vous serez en avance sur la majorité des organisations d'ingénierie.
Vous voulez modéliser votre propre architecture en C4 ? Démarrez avec Archyl. Lisez aussi pourquoi ADRs et C4 fonctionnent mieux ensemble ou comment les Architecture Change Requests apportent la rigueur des pull requests à votre modèle C4.