Aviso. Este artículo se basa íntegramente en las comunicaciones públicas de Netflix — su tech blog, charlas de conferencias, repos open source y casos de estudio externos. No es un documento oficial de arquitectura de Netflix. Modelamos lo que sabemos públicamente para ilustrar cómo un stack complejo puede hacerse legible con el modelo C4. Cuando los detalles son inferidos en vez de afirmados por Netflix, lo decimos.
Anatomía de un Play: modelando Netflix en C4 con Archyl
Cuando pulsas Play en Netflix, alrededor de cincuenta servicios colaboran en menos de 200 milisegundos para empezar a hacer fluir los bytes hacia tu TV.
Autenticación, resolución de perfil, comprobación de elegibilidad, lookup de watch-state, generación de manifest, emisión de licencia DRM, ad decisioning (desde 2023), routing CDN, hit de cache edge, negociación de bitrate, packet pacing — todo eso, antes de que el frame zero llegue a tu pantalla.
Netflix opera más de mil microservicios. Su tech blog menciona casualmente "the membership platform" como si fuera una sola cosa — son doce servicios. "The video pipeline" son docenas de microservicios orquestados a través de tres capas arquitecturales. "Open Connect" es una flota global de diez mil appliances FreeBSD embebidas en redes de ISPs.
¿Cómo entiendes un stack así? No lo entiendes, no de un golpe. Justamente ese es el problema que el modelo C4 fue inventado para resolver.
En este post modelamos la arquitectura de Netflix a través de los cuatro niveles C4 — System Context, Container, Component y Code — y mostramos cómo Archyl hace que un stack de esta escala no solo sea documentable, sino legible.
No cubriremos cada servicio. Nadie podría. Vamos a seguir una sola acción de usuario — pulsar Play — y verla atravesar las capas.
Nivel 1 — System Context: diez cosas, no mil
En el nivel System Context, Netflix no es mil microservicios. Son diez sistemas.
Mirando las comunicaciones públicas de Netflix de los últimos cinco años, diez sistemas distintos emergen de manera consistente:
- Member Experience — signup, billing, cuenta, perfiles, gestión de plan
- Content Discovery — search, recomendaciones, browse, ranking
- Streaming Platform — playback, manifests, DRM, QoE
- Open Connect — el CDN propietario global
- Studio Engineering — herramientas de pre- a post-producción
- Content Engineering — catálogo, metadata, taxonomía
- Data Platform — Kafka, Flink, Iceberg, Atlas, Mantis
- Cloud Platform — Spinnaker, Titus, Eureka, la consola de developer federada
- Security — perímetro, secretos, threat detection
- Ads Platform — añadido en 2023 con el tier ad-supported
Alrededor: members en cientos de tipos de devices, ISPs hospedando Open Connect appliances, AWS como cloud subyacente, partners DRM (Widevine, PlayReady, FairPlay), procesadores de pago y billers partner (App Store, Google Play, bundles telco), studios de contenido en el lado supplier.
Eso es. Diez sistemas, seis categorías de actores externos. Todo lo demás es detalle.
Este es el regalo del Nivel 1: en System Context, no necesitas saber que Membership son doce microservicios. Necesitas saber que existe, que habla con billing, y que un ISP eventualmente hospeda tus bytes. El diagrama es un iniciador de conversación, no un inventario.
ADR-001 · Construir Open Connect, no pagar a un CDN
Estado · Accepted (2011, todavía activo en 2026)
Contexto · El tráfico de streaming crecía exponencialmente. Los CDN comerciales (Akamai, Limelight, Level 3) no podían garantizar calidad por-frame a la escala de Netflix, y la curva de costes era insostenible.
Decisión · Construir un CDN propietario. Embeber appliances dentro de redes de ISPs. Prefetchear de noche cuando las redes están idle. Correr en FreeBSD + NGINX con almacenamiento NVMe + HDD.
Consecuencias · Alrededor del 95% del tráfico de video Netflix es ahora servido directamente por Open Connect. El CDN dejó de ser una línea de coste para convertirse en un foso estratégico. El diagrama de Nivel 1 tiene Open Connect donde cada otro servicio de streaming tiene Akamai.
La decisión de construir Open Connect es la elección arquitectural única que más da forma al diagrama de Nivel 1 de Netflix. Sin ella, el diagrama tendría una caja gigante de Akamai donde el CDN entero está hoy.
En Archyl, así es como un ADR gana su lugar: explica por qué el diagrama tiene la forma que tiene.
Nivel 2 — Container: zoom dentro de Streaming Platform
Pulsa Play, y tu cliente — digamos una Smart TV — golpea Streaming Platform. Abramos la caja.
Dentro de Streaming Platform, las fuentes públicas revelan al menos estos containers:
- Playback API — el punto de entrada. Valida la sesión, comprueba límites de streams concurrentes, decide elegibilidad para el bitrate ladder.
- Manifest Service (Cadmium / Akira en el vocabulario interno de Netflix) — genera el manifest HLS o DASH por sesión, lo firma.
- License Service — handshake con el DRM del device (Widevine para Android/Chrome, PlayReady para Edge/Xbox, FairPlay para Apple).
- MSL Gateway — Message Security Layer propietario de Netflix, el protocolo que hablan los clientes antes de que HTTPS termine dentro de la plataforma.
- FTL (Fast Track Live) — el pipeline de live streaming.
- EVCache — una flota Memcached de 22 000 instancias con 14,3 PB de working set, sirviendo hot reads de sesión y metadata.
- Cassandra clusters — viewing state, watch history, datos de sesión durables.
Un play típico toca Playback API → Manifest Service → License Service en paralelo, todos servidos desde EVCache cuando caliente y desde Cassandra si no. La URL del manifest apunta a una Open Connect appliance — y desde ahí, tu TV habla con un servidor que puede estar literalmente dentro del datacenter de tu ISP, a milisegundos.
El stack tecnológico a este nivel: Java con Spring Boot, gRPC para llamadas inter-servicio, Kafka para events, GraphQL Federation para APIs cliente desde la migración Falcor → GraphQL en 2022.
ADR-002 · Cassandra como datastore por defecto
Estado · Accepted (2011, todavía activo para la mayoría de workloads stateful)
Contexto · El outage de datacenter de Netflix en 2008 demostró que una primary database única es un single point of business failure. Eventual consistency multi-DC, scale lineal en escritura, sin SPOF — se volvieron los nuevos requirements.
Decisión · Adoptar Cassandra como datastore por defecto para nuevos servicios. Aceptar eventual consistency a nivel data. Construir EVCache encima para cubrir el hot read path.
Consecuencias · La mayoría de servicios stateful son Cassandra-backed. Multi-region active-active se vuelve natural. Para workloads que necesitan transacciones SQL globales (membership pricing, redemption codes), CockroachDB se añadió en 2020 — pero Cassandra todavía posee los datos de usuario durables.
Dos ADRs, y el diagrama empieza a tener sentido. Las elecciones de container siguen a las decisiones a nivel sistema, que siguen a las restricciones de negocio.
Nivel 3 — Component: dentro del pipeline de video Cosmos
El encoding no ocurre al momento del play. Ocurre meses antes, cuando un título es ingerido. Pero es un hermoso ejemplo de Nivel 3 — un lugar donde Netflix ha publicado lo suficiente para que podamos cartografiar el interior de uno de sus containers.
Cosmos es la plataforma que reemplazó a Reloaded, el video pipeline previo de Netflix. La migración se completó en septiembre 2023 tras años de trabajo. Cada microservicio Cosmos sigue un patrón de tres capas:
- Optimus — la capa API, expuesta externamente
- Plato — la capa de orquestación de workflow
- Stratum — la capa serverless de compute
Un título moviéndose por encoding atraviesa una cadena de componentes, cada uno un microservicio Cosmos:
- VIS — Video Inspection Service. Sondea el asset fuente.
- CAS — Complexity Analysis Service. Puntúa cuán difícil es de encodear el contenido.
- LGS — Ladder Generation Service. Decide el bitrate ladder.
- VES — Video Encoding Service. Encoding propiamente, paralelizado por chunks.
- VVS — Video Validation Service. Verifica integridad de salida.
- VQS — Video Quality Service. Puntúa el resultado con VMAF, la métrica de calidad perceptual open source de Netflix.
Esto es lo que Component-level C4 parece: no "aquí hay algo de código", sino "aquí está la cadena de primitivas business-meaningful, cada una owned, cada una reemplazable, cada una medible".
ADR-003 · Migrar de Reloaded a Cosmos
Estado · Accepted (empezado ~2018, completado septiembre 2023)
Contexto · Reloaded era un video pipeline monolítico y secuencial. Cuando el catálogo de Netflix creció y la complejidad de codecs explotó (HDR, AV1, encoding por-shot), Reloaded se volvió el cuello de botella — añadir un nuevo codec exigía reconstruir todo el pipeline.
Decisión · Descomponer en microservicios chunk-parallel, cada uno implementando el patrón en tres capas Optimus / Plato / Stratum. Usar Timestone, un sistema de messaging Netflix-interno con awareness de prioridad, para orquestar.
Consecuencias · El throughput de encoding se multiplicó. Los nuevos codecs y experimentos de calidad se volvieron componibles, no catastróficos. La descomposición desbloqueó el encoding por-shot, que mejoró directamente la eficiencia de bitrate para la experiencia del member.
En un modelo Archyl, ADRs como esta viajan con la arquitectura. Cuando haces clic en el container Cosmos en 2026 y ves siete componentes, ves también la decisión de 2018 que explica por qué son siete y no uno.
Tres decisiones. Tres cards en Archyl, cada una linkada a los elementos C4 que da forma — Open Connect a su caja sistema, Cassandra al container de datastore, Cosmos a los componentes que no existían antes de 2018. El diagrama es el presente; los ADRs son el porqué.
Ownership: convertir un modelo en accountability
Un modelo C4 es un artefacto estático hasta que mapeas equipos a él.
Netflix comunica públicamente sobre sus grupos: Member Systems, Studio Engineering, Open Connect (una org distinta hardware-focused), Cloud Platform, Streaming Algorithms, Data Platform, Insight Engineering, Security, Ads Engineering, y Personalization Research.
Pónlos sobre el modelo C4:
- Member Systems posee Member Experience y la Ads Platform
- Studio Engineering posee los containers Studio + Content Engineering
- Open Connect posee el sistema Open Connect entero de arriba a abajo — su integración vertical hardware/software es famosa
- Cloud Platform posee Spinnaker, Titus, Eureka — el tejido plataforma
- Streaming Algorithms posee los componentes de encoding (el pipeline Cosmos)
- Data Platform posee Kafka, Flink, Iceberg, Atlas, Mantis
- Personalization Research posee modelos de reco, search, ranking
Este mapeo no es decoración. Es el sustrato de todo lo que viene después.
Una vez que un sistema, container o componente tiene una equipo propietaria, la detección de drift se vuelve responsable: cuando un nuevo servicio aparece en commits y no está en el diagrama, una equipo específica es interpelada. Cuando una regla de conformidad es violada, hay un nombre en una inbox. Cuando un ADR necesita ser escrito, la ambigüedad colapsa.
En Archyl, el Ownership Map es el momento en que una herramienta de doc se vuelve una herramienta de gobernanza.
Drift, conformidad, y el resumen semanal
Un modelo de este tamaño va a derivar. Nuevos servicios llegan. Los viejos se retiran. Los stacks cambian — Falcor → GraphQL Federation, Reloaded → Cosmos, Hystrix → maintenance.
Archyl computa un score de drift semanal: la brecha entre el modelo C4 documentado y lo que está actualmente en el código. Las reglas de conformidad añaden la capa de policy — "cada container necesita una equipo propietaria", "sin acceso cross-database", "cada tecno marcada ADR debe estar en el radar".
Para Netflix, eso es detección de drift a la escala de mil servicios. Pero las reglas son las mismas que para diez.
Y el Resumen de Arquitectura de Equipo que lanzamos la semana pasada, en un setup tipo Netflix, significaría:
- El resumen del lunes de Member Systems cubre sus doce microservicios de membership
- El resumen de Open Connect cubre las OCAs y el control plane
- El resumen de Streaming Algorithms cubre Cosmos y los componentes de encoding
- Cada resumen scoped al perímetro propio de su equipo, en su zona horaria
Misma superficie. Diferentes scopes. Esa es la simetría que C4 + ownership desbloquean.
No necesitas mil servicios
No eres Netflix. La mayoría de organizaciones de ingeniería no lo son.
Pero la lección escala también hacia abajo. La disciplina de separar Context de Container de Component, de escribir el ADR que explica el diagrama, de adjuntar ownership a cada caja — esa disciplina es lo que evita que un stack de cincuenta servicios se sienta como mil.
C4 + ADRs + Ownership + Drift + Conformidad es lo que Archyl te da out of the box. El ejemplo Netflix es solo el más grande stress-test plausible del modelo.
Abre tu propia arquitectura. Esquematiza diez sistemas. Elige el que más duele, zoomea en sus containers. Escribe tres ADRs explicando por qué las elecciones tienen la forma que tienen. Mapea una equipo a cada container.
Estarás por delante de donde la mayoría de organizaciones de ingeniería llegan en un año.
¿Quieres modelar tu propia arquitectura en C4? Empieza con Archyl. Lee también por qué ADRs y C4 funcionan mejor juntos o cómo los Architecture Change Requests aportan rigor de pull request a tu modelo C4.