Aviso. Este artigo é baseado inteiramente em comunicações públicas da Netflix — seu tech blog, palestras de conferências, repos open source e estudos de caso externos. Não é um documento de arquitetura oficial Netflix. Modelamos o que sabemos publicamente para ilustrar como um stack complexo pode ser tornado legível com o modelo C4. Quando os detalhes são inferidos em vez de afirmados pela Netflix, dizemos.
Anatomia de um Play: modelando a Netflix em C4 com Archyl
Quando você aperta Play na Netflix, cerca de cinquenta serviços colaboram em menos de 200 milissegundos para começar a fazer os bytes fluírem para sua TV.
Autenticação, resolução de perfil, verificação de elegibilidade, lookup de watch-state, geração de manifest, emissão de licença DRM, ad decisioning (desde 2023), routing CDN, hit de cache edge, negociação de bitrate, packet pacing — tudo isso, antes do frame zero atingir sua tela.
A Netflix opera mais de mil microsserviços. O tech blog deles menciona casualmente "the membership platform" como se fosse uma coisa só — são doze serviços. "The video pipeline" são dezenas de microsserviços orquestrados em três camadas arquiteturais. "Open Connect" é uma frota global de dez mil appliances FreeBSD embarcadas em redes de ISPs.
Como você entende um stack desses? Você não entende, não de uma vez. É exatamente o problema que o modelo C4 foi inventado para resolver.
Neste post modelamos a arquitetura da Netflix através dos quatro níveis C4 — System Context, Container, Component e Code — e mostramos como o Archyl torna um stack desta escala não só documentável, mas legível.
Não vamos cobrir cada serviço. Ninguém poderia. Vamos seguir uma única ação de usuário — apertar Play — e vê-la atravessar as camadas.
Nível 1 — System Context: dez coisas, não mil
No nível System Context, a Netflix não é mil microsserviços. São dez sistemas.
Olhando as comunicações públicas da Netflix nos últimos cinco anos, dez sistemas distintos emergem de forma consistente:
- Member Experience — signup, billing, conta, perfis, gestão de plano
- Content Discovery — search, recomendações, browse, ranking
- Streaming Platform — playback, manifests, DRM, QoE
- Open Connect — o CDN proprietário global
- Studio Engineering — ferramentas da pré- à pós-produção
- Content Engineering — catálogo, metadata, taxonomia
- Data Platform — Kafka, Flink, Iceberg, Atlas, Mantis
- Cloud Platform — Spinnaker, Titus, Eureka, o console developer federado
- Security — perímetro, secrets, threat detection
- Ads Platform — adicionado em 2023 com o tier ad-supported
Em torno: members em centenas de tipos de devices, ISPs hospedando Open Connect appliances, AWS como cloud subjacente, parceiros DRM (Widevine, PlayReady, FairPlay), processadores de pagamento e billers parceiros (App Store, Google Play, bundles telco), studios de conteúdo no lado fornecedor.
É isso. Dez sistemas, seis categorias de atores externos. Tudo o resto é detalhe.
Esse é o presente do Nível 1: no System Context, você não precisa saber que Membership são doze microsserviços. Você precisa saber que ele existe, que conversa com billing, e que um ISP eventualmente hospeda seus bytes. O diagrama é um iniciador de conversa, não um inventário.
ADR-001 · Construir Open Connect, não pagar um CDN
Status · Accepted (2011, ainda ativo em 2026)
Contexto · O tráfego de streaming crescia exponencialmente. CDNs comerciais (Akamai, Limelight, Level 3) não conseguiam garantir qualidade por-frame na escala da Netflix, e a curva de custo era insustentável.
Decisão · Construir um CDN proprietário. Embarcar appliances dentro de redes de ISPs. Prefetchar à noite quando as redes estão idle. Rodar em FreeBSD + NGINX com storage NVMe + HDD.
Consequências · Cerca de 95% do tráfego de vídeo Netflix é agora servido diretamente pelo Open Connect. O CDN deixou de ser uma linha de custo para se tornar um fosso estratégico. O diagrama de Nível 1 tem Open Connect onde cada outro serviço de streaming tem Akamai.
A decisão de construir Open Connect é a escolha arquitetural única que mais dá forma ao diagrama de Nível 1 da Netflix. Sem ela, o diagrama teria uma caixa gigante Akamai onde hoje está o CDN inteiro.
No Archyl, é assim que um ADR ganha seu lugar: explica por que o diagrama tem a forma que tem.
Nível 2 — Container: zoom dentro de Streaming Platform
Aperte Play, e seu cliente — digamos uma Smart TV — atinge Streaming Platform. Vamos abrir a caixa.
Dentro de Streaming Platform, fontes públicas revelam pelo menos estes containers:
- Playback API — o ponto de entrada. Valida a sessão, checa limites de streams concorrentes, decide elegibilidade para o bitrate ladder.
- Manifest Service (Cadmium / Akira no vocabulário interno da Netflix) — gera o manifest HLS ou DASH por sessão, assina-o.
- License Service — handshake com o DRM do device (Widevine para Android/Chrome, PlayReady para Edge/Xbox, FairPlay para Apple).
- MSL Gateway — Message Security Layer proprietário da Netflix, o protocolo que clientes falam antes de HTTPS terminar dentro da plataforma.
- FTL (Fast Track Live) — o pipeline de live streaming.
- EVCache — uma frota Memcached de 22 000 instâncias com 14,3 PB de working set, fronting hot reads de sessão e metadata.
- Clusters Cassandra — viewing state, watch history, dados de sessão duráveis.
Um play típico toca Playback API → Manifest Service → License Service em paralelo, todos servidos do EVCache quando quente e do Cassandra quando não. A URL do manifest aponta para uma Open Connect appliance — e a partir daí, sua TV conversa com um servidor que pode literalmente estar dentro do datacenter do seu ISP, a milissegundos.
O stack tecnológico neste nível: Java com Spring Boot, gRPC para chamadas inter-serviço, Kafka para eventos, GraphQL Federation para APIs cliente desde a migração Falcor → GraphQL em 2022.
ADR-002 · Cassandra como datastore default
Status · Accepted (2011, ainda ativo para a maioria dos workloads stateful)
Contexto · O outage de datacenter da Netflix em 2008 provou que um banco primary único é um single point of business failure. Eventual consistency multi-DC, scale linear em escrita e zero SPOF tornaram-se os novos requisitos.
Decisão · Adotar Cassandra como datastore default para novos serviços. Aceitar eventual consistency na camada de dados. Construir EVCache em cima para cobrir o hot read path.
Consequências · A maioria dos serviços stateful são Cassandra-backed. Multi-region active-active fica natural. Para workloads que precisam de transações SQL globais (membership pricing, redemption codes), CockroachDB foi adicionado em 2020 — mas Cassandra ainda possui os dados de usuário duráveis.
Dois ADRs, e o diagrama começa a fazer sentido. Escolhas de container seguem decisões de nível sistema, que seguem restrições de negócio.
Nível 3 — Component: dentro do pipeline de vídeo Cosmos
Encoding não acontece na hora do play. Acontece meses antes, quando um título é ingerido. Mas é um lindo exemplo de Nível 3 — um lugar onde a Netflix publicou o suficiente para podermos cartografar o interior de um dos containers deles.
Cosmos é a plataforma que substituiu Reloaded, o pipeline de vídeo anterior da Netflix. A migração foi completada em setembro de 2023 após anos de trabalho. Cada microsserviço Cosmos segue um padrão de três camadas:
- Optimus — a camada API, exposta externamente
- Plato — a camada de orquestração de workflow
- Stratum — a camada serverless de compute
Um título passando por encoding atravessa uma cadeia de componentes, cada um um microsserviço Cosmos:
- VIS — Video Inspection Service. Sonda o asset fonte.
- CAS — Complexity Analysis Service. Pontua quão difícil é encodar o conteúdo.
- LGS — Ladder Generation Service. Decide o bitrate ladder.
- VES — Video Encoding Service. Encoding propriamente, paralelizado por chunks.
- VVS — Video Validation Service. Verifica integridade de saída.
- VQS — Video Quality Service. Pontua o resultado com VMAF, a métrica de qualidade perceptual open source da Netflix.
Isso é o que Component-level C4 parece: não "aqui está algum código", mas "aqui está a cadeia de primitivas business-meaningful, cada uma owned, cada uma substituível, cada uma mensurável".
ADR-003 · Migrar de Reloaded para Cosmos
Status · Accepted (iniciado ~2018, completado setembro 2023)
Contexto · Reloaded era um pipeline de vídeo monolítico e sequencial. Quando o catálogo da Netflix cresceu e a complexidade de codecs explodiu (HDR, AV1, encoding por-shot), Reloaded virou o gargalo — adicionar um novo codec exigia reconstruir o pipeline inteiro.
Decisão · Decompor em microsserviços chunk-parallel, cada um implementando o padrão de três camadas Optimus / Plato / Stratum. Usar Timestone, um sistema de messaging Netflix-interno priority-aware, para orquestrar.
Consequências · O throughput de encoding multiplicou. Novos codecs e experimentos de qualidade ficaram componíveis, não catastróficos. A decomposição desbloqueou encoding por-shot, que melhorou diretamente a eficiência de bitrate para a experiência do member.
Em um modelo Archyl, ADRs como este viajam com a arquitetura. Quando você clica no container Cosmos em 2026 e vê sete componentes, vê também a decisão de 2018 que explica por que são sete e não um.
Três decisões. Três cards no Archyl, cada uma linkada aos elementos C4 que ela molda — Open Connect à sua caixa de sistema, Cassandra ao container datastore, Cosmos aos componentes que não existiam antes de 2018. O diagrama é o presente; os ADRs são o porquê.
Ownership: transformar um modelo em accountability
Um modelo C4 é um artefato estático até você mapear equipes nele.
A Netflix comunica publicamente sobre seus grupos: Member Systems, Studio Engineering, Open Connect (uma org distinta hardware-focused), Cloud Platform, Streaming Algorithms, Data Platform, Insight Engineering, Security, Ads Engineering, e Personalization Research.
Coloque-os no modelo C4:
- Member Systems possui Member Experience e a Ads Platform
- Studio Engineering possui os containers Studio + Content Engineering
- Open Connect possui o sistema Open Connect inteiro de cima a baixo — sua integração vertical hardware/software é famosa
- Cloud Platform possui Spinnaker, Titus, Eureka — o tecido plataforma
- Streaming Algorithms possui os componentes de encoding (o pipeline Cosmos)
- Data Platform possui Kafka, Flink, Iceberg, Atlas, Mantis
- Personalization Research possui modelos de reco, search, ranking
Esse mapeamento não é decoração. É o substrato de tudo que vem depois.
Uma vez que um sistema, container ou componente tem uma equipe proprietária, a detecção de drift fica responsável: quando um novo serviço aparece em commits e não está no diagrama, uma equipe específica é interpelada. Quando uma regra de conformidade é violada, há um nome em uma inbox. Quando um ADR precisa ser escrito, a ambiguidade colapsa.
No Archyl, o Ownership Map é o momento em que uma ferramenta de doc vira uma ferramenta de governança.
Drift, conformidade, e o resumo semanal
Um modelo desse tamanho vai derivar. Novos serviços chegam. Os antigos são aposentados. Os stacks mudam — Falcor → GraphQL Federation, Reloaded → Cosmos, Hystrix → maintenance.
Archyl computa um drift score semanal: o gap entre o modelo C4 documentado e o que está atualmente no código. Regras de conformidade adicionam a camada de policy — "todo container precisa de uma equipe proprietária", "sem acesso cross-database", "toda tech marcada ADR deve estar no radar".
Para a Netflix, isso é detecção de drift na escala de mil serviços. Mas as regras são as mesmas que para dez.
E o Resumo de Arquitetura de Equipe que lançamos semana passada, num setup tipo Netflix, significaria:
- O resumo de segunda da Member Systems cobre seus doze microsserviços de membership
- O resumo da Open Connect cobre as OCAs e o control plane
- O resumo da Streaming Algorithms cobre Cosmos e os componentes de encoding
- Cada resumo scoped ao perímetro da equipe, no seu próprio fuso horário
Mesma superfície. Scopes diferentes. É a simetria que C4 + ownership desbloqueiam.
Você não precisa de mil serviços
Você não é a Netflix. A maioria das organizações de engenharia não é.
Mas a lição escala também para baixo. A disciplina de separar Context de Container de Component, de escrever o ADR que explica o diagrama, de anexar ownership a cada caixa — essa disciplina é o que impede um stack de cinquenta serviços de parecer mil.
C4 + ADRs + Ownership + Drift + Conformidade é o que Archyl te dá out of the box. O exemplo Netflix é só o maior stress-test plausível do modelo.
Abra sua própria arquitetura. Esboce dez sistemas. Pegue o que mais dói, zoom nos containers dele. Escreva três ADRs explicando por que as escolhas têm a forma que têm. Mapeie uma equipe a cada container.
Você estará à frente de onde a maioria das organizações de engenharia chega em um ano.
Quer modelar sua própria arquitetura em C4? Comece com Archyl. Leia também por que ADRs e C4 funcionam melhor juntos ou como Architecture Change Requests trazem o rigor da pull request ao seu modelo C4.