Disclaimer. Questo articolo si basa interamente sulle comunicazioni pubbliche di Netflix — il loro tech blog, talk a conferenze, repository open source e case study esterni. Non è un documento di architettura ufficiale Netflix. Modelliamo ciò che sappiamo pubblicamente per illustrare come uno stack complesso possa essere reso leggibile con il modello C4. Quando i dettagli sono inferiti invece che affermati da Netflix, lo diciamo.
Anatomia di un Play: modellare Netflix in C4 con Archyl
Quando premi Play su Netflix, circa cinquanta servizi collaborano in meno di 200 millisecondi per iniziare a far scorrere i byte verso la tua TV.
Autenticazione, risoluzione del profilo, controllo eligibilità, lookup del watch-state, generazione del manifest, emissione della licenza DRM, ad decisioning (dal 2023), routing CDN, hit della cache edge, negoziazione del bitrate, packet pacing — tutto questo, prima che il frame zero arrivi sul tuo schermo.
Netflix opera oltre mille microservizi. Il loro tech blog menziona disinvoltamente "the membership platform" come fosse una cosa sola — sono dodici servizi. "The video pipeline" sono dozzine di microservizi orchestrati su tre layer architetturali. "Open Connect" è una flotta globale di diecimila appliance FreeBSD incorporate nelle reti degli ISP.
Come si comprende uno stack del genere? Non si comprende, non in un colpo solo. È esattamente il problema che il modello C4 è stato inventato per risolvere.
In questo post modelliamo l'architettura di Netflix sui quattro livelli C4 — System Context, Container, Component e Code — e mostriamo come Archyl rende uno stack di questa scala non solo documentabile, ma leggibile.
Non copriremo ogni servizio. Nessuno potrebbe. Seguiremo una sola azione utente — premere Play — e la guarderemo attraversare i livelli.
Livello 1 — System Context: dieci cose, non mille
Al livello System Context, Netflix non è mille microservizi. Sono dieci sistemi.
Guardando le comunicazioni pubbliche di Netflix degli ultimi cinque anni, dieci sistemi distinti emergono in modo coerente:
- Member Experience — signup, billing, account, profili, gestione piano
- Content Discovery — search, raccomandazioni, browse, ranking
- Streaming Platform — playback, manifest, DRM, QoE
- Open Connect — il CDN proprietario globale
- Studio Engineering — strumenti dalla pre- alla post-produzione
- Content Engineering — catalogo, metadata, tassonomia
- Data Platform — Kafka, Flink, Iceberg, Atlas, Mantis
- Cloud Platform — Spinnaker, Titus, Eureka, la console developer federata
- Security — perimetro, secret, threat detection
- Ads Platform — aggiunto nel 2023 con il tier ad-supported
Intorno: member su centinaia di tipi di device, ISP che ospitano Open Connect appliance, AWS come cloud sottostante, partner DRM (Widevine, PlayReady, FairPlay), processori di pagamento e biller partner (App Store, Google Play, bundle telco), studi di contenuto sul lato fornitore.
Tutto qui. Dieci sistemi, sei categorie di attori esterni. Tutto il resto è dettaglio.
Questo è il regalo del Livello 1: al System Context non hai bisogno di sapere che Membership è dodici microservizi. Ti basta sapere che esiste, che parla con il billing, e che un ISP alla fine ospita i tuoi byte. Il diagramma è un avviatore di conversazione, non un inventario.
ADR-001 · Costruire Open Connect, non pagare un CDN
Stato · Accepted (2011, ancora attivo nel 2026)
Contesto · Il traffico di streaming cresceva esponenzialmente. I CDN commerciali (Akamai, Limelight, Level 3) non potevano garantire la qualità per-frame alla scala di Netflix, e la curva dei costi era insostenibile.
Decisione · Costruire un CDN proprietario. Incorporare appliance dentro le reti degli ISP. Prefetch notturno quando le reti sono idle. Far girare su FreeBSD + NGINX con storage NVMe + HDD.
Conseguenze · Circa il 95% del traffico video Netflix è ora servito direttamente da Open Connect. Il CDN ha cessato di essere una linea di costo per diventare un fossato strategico. Il diagramma di Livello 1 ha Open Connect dove ogni altro servizio di streaming ha Akamai.
La decisione di costruire Open Connect è la singola scelta architetturale che più dà forma al diagramma di Livello 1 di Netflix. Senza di essa, il diagramma avrebbe una grossa scatola Akamai dove oggi siede l'intero CDN.
In Archyl, è così che un ADR si guadagna il suo posto: spiega perché il diagramma ha la forma che ha.
Livello 2 — Container: zoom in Streaming Platform
Premi Play, e il tuo client — diciamo una Smart TV — colpisce Streaming Platform. Apriamo la scatola.
Dentro Streaming Platform, le fonti pubbliche rivelano almeno questi container:
- Playback API — il punto di ingresso. Valida la sessione, controlla i limiti di stream concorrenti, decide l'eligibilità per il bitrate ladder.
- Manifest Service (Cadmium / Akira nel vocabolario interno Netflix) — genera il manifest HLS o DASH per sessione, lo firma.
- License Service — handshake con il DRM del device (Widevine per Android/Chrome, PlayReady per Edge/Xbox, FairPlay per Apple).
- MSL Gateway — Message Security Layer proprietario di Netflix, il protocollo che i client parlano prima che HTTPS termini dentro la piattaforma.
- FTL (Fast Track Live) — la pipeline di live streaming.
- EVCache — una flotta Memcached da 22 000 istanze con 14,3 PB di working set, che fronta hot read di sessione e metadata.
- Cluster Cassandra — viewing state, watch history, dati di sessione durabili.
Un play tipico tocca Playback API → Manifest Service → License Service in parallelo, tutti serviti da EVCache quando caldi e da Cassandra altrimenti. L'URL del manifest punta a un'Open Connect appliance — e da lì, la tua TV parla con un server che può letteralmente essere dentro il datacenter del tuo ISP, a millisecondi di distanza.
Lo stack tecnologico a questo livello: Java con Spring Boot, gRPC per chiamate inter-servizio, Kafka per gli event, GraphQL Federation per le API client dalla migrazione Falcor → GraphQL nel 2022.
ADR-002 · Cassandra come datastore di default
Stato · Accepted (2011, ancora attivo per la maggior parte dei workload stateful)
Contesto · L'outage del datacenter Netflix nel 2008 ha dimostrato che un primary database singolo è un single point of business failure. Eventual consistency multi-DC, scale lineare in scrittura e nessun SPOF sono diventati i nuovi requirement.
Decisione · Adottare Cassandra come datastore di default per i nuovi servizi. Accettare l'eventual consistency a livello data. Costruire EVCache sopra per coprire il hot read path.
Conseguenze · La maggior parte dei servizi stateful sono Cassandra-backed. Il multi-region active-active diventa naturale. Per workload che richiedono transazioni SQL globali (membership pricing, redemption code), CockroachDB è stato aggiunto nel 2020 — ma Cassandra possiede ancora i dati utente durabili.
Due ADR, e il diagramma comincia ad avere senso. Le scelte di container seguono dalle decisioni a livello di sistema, che seguono dai vincoli di business.
Livello 3 — Component: dentro la pipeline video Cosmos
L'encoding non avviene al momento del play. Avviene mesi prima, quando un titolo viene ingerito. Ma è un bell'esempio di Livello 3 — un posto dove Netflix ha pubblicato abbastanza perché si possa cartografare l'interno di uno dei loro container.
Cosmos è la piattaforma che ha sostituito Reloaded, la precedente video pipeline di Netflix. La migrazione si è completata a settembre 2023 dopo anni di lavoro. Ogni microservizio Cosmos segue un pattern a tre layer:
- Optimus — il layer API, esposto esternamente
- Plato — il layer di orchestrazione del workflow
- Stratum — il layer serverless di compute
Un titolo che attraversa l'encoding percorre una catena di componenti, ognuno un microservizio Cosmos:
- VIS — Video Inspection Service. Sonda l'asset sorgente.
- CAS — Complexity Analysis Service. Punteggia quanto è duro encodare il contenuto.
- LGS — Ladder Generation Service. Decide il bitrate ladder.
- VES — Video Encoding Service. Encoding vero e proprio, parallelizzato per chunk.
- VVS — Video Validation Service. Verifica l'integrità dell'output.
- VQS — Video Quality Service. Punteggia il risultato con VMAF, la metrica di qualità percettiva open source di Netflix.
Ecco a cosa assomiglia il C4 a livello Component: non "ecco del codice", ma "ecco la catena di primitivi business-meaningful, ognuno owned, ognuno rimpiazzabile, ognuno misurabile".
ADR-003 · Migrare da Reloaded a Cosmos
Stato · Accepted (iniziato ~2018, completato settembre 2023)
Contesto · Reloaded era una pipeline video monolitica e sequenziale. Quando il catalogo di Netflix è cresciuto e la complessità dei codec è esplosa (HDR, AV1, encoding per-shot), Reloaded è diventato il collo di bottiglia — aggiungere un nuovo codec richiedeva di ricostruire l'intera pipeline.
Decisione · Decomporre in microservizi chunk-parallel, ognuno implementando il pattern a tre layer Optimus / Plato / Stratum. Usare Timestone, un sistema di messaging Netflix-interno priority-aware, per orchestrare.
Conseguenze · Il throughput di encoding è stato moltiplicato. I nuovi codec ed esperimenti di qualità sono diventati componibili, non catastrofici. La decomposizione ha sbloccato l'encoding per-shot, che ha migliorato direttamente l'efficienza di bitrate per l'esperienza member.
In un modello Archyl, ADR come questo viaggiano con l'architettura. Quando clicchi nel container Cosmos nel 2026 e vedi sette componenti, vedi anche la decisione del 2018 che spiega perché sono sette e non uno.
Tre decisioni. Tre card in Archyl, ognuna linkata agli elementi C4 che dà forma — Open Connect alla sua scatola sistema, Cassandra al container datastore, Cosmos ai componenti che non esistevano prima del 2018. Il diagramma è il presente; gli ADR sono il perché.
Ownership: trasformare un modello in accountability
Un modello C4 è un artefatto statico finché non mappi i team su di esso.
Netflix comunica pubblicamente sui suoi gruppi: Member Systems, Studio Engineering, Open Connect (un'organizzazione distinta hardware-focused), Cloud Platform, Streaming Algorithms, Data Platform, Insight Engineering, Security, Ads Engineering, e Personalization Research.
Posiziona questi sul modello C4:
- Member Systems possiede Member Experience e la Ads Platform
- Studio Engineering possiede i container Studio + Content Engineering
- Open Connect possiede l'intero sistema Open Connect dall'alto al basso — la loro integrazione verticale hardware/software è famosa
- Cloud Platform possiede Spinnaker, Titus, Eureka — il tessuto piattaforma
- Streaming Algorithms possiede i componenti di encoding (la pipeline Cosmos)
- Data Platform possiede Kafka, Flink, Iceberg, Atlas, Mantis
- Personalization Research possiede modelli di reco, search, ranking
Questa mappatura non è decorativa. È il sostrato di tutto ciò che viene dopo.
Una volta che un sistema, container o componente ha un team proprietario, la rilevazione di drift diventa responsabile: quando un nuovo servizio appare nei commit e non è sul diagramma, un team specifico viene interpellato. Quando una regola di conformità viene violata, c'è un nome in una inbox. Quando un ADR deve essere scritto, l'ambiguità collassa.
In Archyl, l'Ownership Map è il momento in cui uno strumento di documentazione diventa uno strumento di governance.
Drift, conformità, e il digest settimanale
Un modello di queste dimensioni andrà in deriva. Nuovi servizi arrivano. I vecchi vengono ritirati. Gli stack cambiano — Falcor → GraphQL Federation, Reloaded → Cosmos, Hystrix → maintenance.
Archyl calcola un drift score settimanale: il gap tra il modello C4 documentato e ciò che è attualmente nel codice. Le regole di conformità aggiungono il layer di policy — "ogni container ha bisogno di un team proprietario", "nessun accesso cross-database", "ogni tecnologia marcata ADR deve essere nel radar".
Per Netflix è rilevazione di drift alla scala di mille servizi. Ma le regole sono le stesse che per dieci.
E il Digest di Architettura di Team che abbiamo rilasciato la scorsa settimana, in un setup tipo Netflix, vorrebbe dire:
- Il digest del lunedì di Member Systems copre i loro dodici microservizi di membership
- Il digest di Open Connect copre le OCA e il control plane
- Il digest di Streaming Algorithms copre Cosmos e i componenti di encoding
- Ogni digest scoped al perimetro posseduto dal proprio team, nel proprio fuso orario
Stessa superficie. Scope diversi. È la simmetria che C4 + ownership sbloccano.
Non hai bisogno di mille servizi
Non sei Netflix. La maggior parte delle organizzazioni di engineering non lo sono.
Ma la lezione scala anche verso il basso. La disciplina di separare Context da Container da Component, di scrivere l'ADR che spiega il diagramma, di attaccare l'ownership a ogni scatola — quella disciplina è ciò che impedisce a uno stack di cinquanta servizi di sembrarne mille.
C4 + ADR + Ownership + Drift + Conformità è ciò che Archyl ti dà out of the box. L'esempio Netflix è solo il più grande stress-test plausibile del modello.
Apri la tua architettura. Schizza dieci sistemi. Scegli quello che fa più male, zoomma nei suoi container. Scrivi tre ADR che spiegano perché le scelte hanno la forma che hanno. Mappa un team a ogni container.
Sarai avanti rispetto a dove la maggior parte delle organizzazioni di engineering arriva in un anno.
Vuoi modellare la tua architettura in C4? Inizia con Archyl. Leggi anche perché ADR e C4 funzionano meglio insieme o come gli Architecture Change Requests portano il rigore della pull request al tuo modello C4.