Disclaimer. This article is based entirely on Netflix's public communications — their tech blog, conference talks, open source repositories, and external case studies. It is not an official Netflix architecture document. We model what we know publicly to illustrate how a complex stack can be made legible with the C4 model. Where details are inferred rather than stated by Netflix, we say so.
Anatomy of a Play: Modeling Netflix in C4 with Archyl
When you press Play on Netflix, around fifty services collaborate in less than 200 milliseconds to start the bytes flowing into your TV.
Authentication, profile resolution, eligibility check, watch-state lookup, manifest generation, DRM license issuance, ad decisioning (since 2023), CDN routing, edge cache hit, bitrate negotiation, packet pacing — all of that, before frame zero hits your screen.
Netflix runs over a thousand microservices. Their tech blog routinely casually mentions "the membership platform" as if it were one thing — it's twelve services. "The video pipeline" is dozens of microservices orchestrated across three architectural layers. "Open Connect" is a globe-spanning fleet of ten thousand FreeBSD appliances embedded in ISP networks.
How do you understand a stack like this? You don't, not all at once. That's exactly the problem the C4 model was invented to solve.
In this post we model Netflix's architecture across the four C4 levels — System Context, Container, Component, and Code — and show how Archyl makes a stack of this scale not just documentable, but legible.
We won't cover every service. No one could. We'll follow one user action — pressing Play — and watch it traverse the layers.
Level 1 — System Context: ten things, not a thousand
At the System Context level, Netflix isn't a thousand microservices. It's ten systems.
Looking at Netflix's public communications over the past five years, ten distinct systems emerge consistently:
- Member Experience — signup, billing, account, profiles, plan management
- Content Discovery — search, recommendations, browse, ranking
- Streaming Platform — playback, manifests, DRM, QoE
- Open Connect — the proprietary global CDN
- Studio Engineering — pre-production through post-production tooling
- Content Engineering — catalog, metadata, taxonomy
- Data Platform — Kafka, Flink, Iceberg, Atlas, Mantis
- Cloud Platform — Spinnaker, Titus, Eureka, the federated developer console
- Security — perimeter, secrets, threat detection
- Ads Platform — added in 2023 with the ad-supported tier
Around them: members on hundreds of device types, ISPs hosting Open Connect appliances, AWS as the underlying cloud, DRM partners (Widevine, PlayReady, FairPlay), payment processors and partner billers (App Store, Google Play, telco bundles), content studios on the supplier side.
That's it. Ten systems, six categories of external actors. Everything else is detail.
This is the gift of Level 1: at System Context, you don't care that Membership is twelve microservices. You care that it exists, that it talks to billing, and that an ISP eventually hosts your bytes.
ADR-001 · Build Open Connect, don't pay a CDN
Status · Accepted (2011, still active in 2026)
Context · Streaming traffic was growing exponentially. Commercial CDNs (Akamai, Limelight, Level 3) couldn't guarantee per-frame quality at Netflix's scale, and the cost curve was unsustainable.
Decision · Build a proprietary CDN. Embed appliances inside ISP networks. Prefetch overnight when networks are idle. Run on FreeBSD + NGINX with NVMe + HDD storage.
Consequences · Around 95% of Netflix video traffic is now served directly by Open Connect. The CDN ceased being a cost line and became a strategic moat. The Level 1 diagram has Open Connect where every other streaming service has Akamai.
The decision to build Open Connect is the single architectural choice that most shapes Netflix's Level 1 diagram. Without it, the diagram would have a giant Akamai box where the entire CDN sits today.
In Archyl, that's how an ADR earns its place: it explains why the diagram looks the way it does.
Level 2 — Container: zoom into the Streaming Platform
Press Play, and your client — let's say a Smart TV — hits the Streaming Platform. Let's open the box.
Inside Streaming Platform, public sources reveal at least these containers:
- Playback API — the entry point. Validates the session, checks concurrent stream limits, decides eligibility for the bitrate ladder.
- Manifest Service (Cadmium / Akira in Netflix's internal vocabulary) — generates the per-session HLS or DASH manifest, signs it.
- License Service — handshakes with the device's DRM (Widevine for Android/Chrome, PlayReady for Edge/Xbox, FairPlay for Apple).
- MSL Gateway — Netflix's proprietary Message Security Layer, the protocol clients speak before HTTPS terminates inside the platform.
- FTL (Fast Track Live) — the live streaming pipeline.
- EVCache — a 22 000-instance Memcached fleet with 14.3 PB of working set, fronting hot session and metadata reads.
- Cassandra clusters — viewing state, watch history, durable session data.
A typical play touches Playback API → Manifest Service → License Service in parallel, all served from EVCache when warm and Cassandra when not. The manifest URL points to an Open Connect appliance — and from there, your TV talks to a server that may literally be inside your ISP's data center, milliseconds away.
The technology stack at this level: Java with Spring Boot, gRPC for inter-service calls, Kafka for events, GraphQL Federation for client APIs since the Falcor → GraphQL migration in 2022.
ADR-002 · Cassandra as the default datastore
Status · Accepted (2011, still active for most stateful workloads)
Context · Netflix's 2008 datacenter outage proved that a single primary database is a single point of business failure. Multi-DC eventual consistency, linear write scale, and no single point of failure became the new requirements.
Decision · Adopt Cassandra as the default datastore for new services. Accept eventual consistency at the data layer. Build EVCache on top to cover the hot read path.
Consequences · Most of Netflix's stateful services are Cassandra-backed. Multi-region active-active became natural. For workloads needing global SQL transactions (membership pricing, redemption codes), CockroachDB was added in 2020 — but Cassandra still owns the durable user data.
Two ADRs in, and the diagram is starting to make sense. Container choices follow from system-level decisions, which follow from business constraints.
Level 3 — Component: inside the Cosmos video pipeline
Encoding doesn't happen at play time. It happens months earlier, when a title is ingested. But it's a beautiful Level 3 example — a place where Netflix has published enough that we can map the inside of one of their containers.
Cosmos is the platform that replaced Reloaded, Netflix's previous video pipeline. The migration completed in September 2023 after years of work. Each Cosmos microservice follows a three-layer pattern:
- Optimus — the API layer, exposed externally
- Plato — the workflow orchestration layer
- Stratum — the serverless compute layer
A title moving through encoding traverses a chain of components, each a Cosmos microservice:
- VIS — Video Inspection Service. Probes the source asset.
- CAS — Complexity Analysis Service. Scores how hard the content is to encode.
- LGS — Ladder Generation Service. Decides the bitrate ladder.
- VES — Video Encoding Service. Actual encoding, parallelized chunk-wise.
- VVS — Video Validation Service. Verifies output integrity.
- VQS — Video Quality Service. Scores the result with VMAF, Netflix's open-source perceptual quality metric.
This is what Component-level C4 looks like: not "here's some code", but "here's the chain of business-meaningful primitives, each owned, each replaceable, each measurable".
ADR-003 · Migrate from Reloaded to Cosmos
Status · Accepted (started ~2018, completed September 2023)
Context · Reloaded was a monolithic, sequential video pipeline. As Netflix's catalog grew and codec complexity exploded (HDR, AV1, per-shot encoding), Reloaded became the bottleneck — adding a new codec required rebuilding the entire pipeline.
Decision · Decompose into chunk-parallel microservices, each implementing the Optimus/Plato/Stratum layered pattern. Use Timestone, a Netflix-internal priority-aware messaging system, to orchestrate.
Consequences · Encoding throughput multiplied. New codecs and quality experiments became composable, not catastrophic. The decomposition unlocked per-shot encoding, which directly improved bitrate efficiency for member experience.
In an Archyl model, ADRs like this one travel with the architecture. When you click into the Cosmos container in 2026 and see seven components, you also see the 2018 decision that explains why it's seven and not one.
Three decisions. Three cards in Archyl, each linked to the C4 elements it shapes — Open Connect to its system box, Cassandra to the datastore container, Cosmos to the components that didn't exist before 2018. The diagram is the present tense; the ADRs are the why.
Ownership: turning a model into accountability
A C4 model is a static artifact until you map teams to it.
Netflix communicates publicly about their groups: Member Systems, Studio Engineering, Open Connect (a distinct hardware-focused org), Cloud Platform, Streaming Algorithms, Data Platform, Insight Engineering, Security, Ads Engineering, and Personalization Research.
Drop these onto the C4 model:
- Member Systems owns Member Experience and the Ads Platform
- Studio Engineering owns the Studio + Content Engineering containers
- Open Connect owns the entire Open Connect system top to bottom — their hardware/software vertical integration is famous
- Cloud Platform owns Spinnaker, Titus, Eureka — the platform fabric
- Streaming Algorithms owns the encoding components (the Cosmos pipeline)
- Data Platform owns Kafka, Flink, Iceberg, Atlas, Mantis
- Personalization Research owns recommendation models, search, ranking
This mapping isn't decoration. It's the substrate for everything that comes next.
Once a system, container, or component has a team owner, drift detection becomes accountable: when a new service appears in commits and isn't on the diagram, a specific team gets asked. When a conformance rule is violated, there's a name in an inbox. When an ADR needs to be written, ambiguity collapses.
In Archyl, the Ownership Map is the moment a documentation tool becomes a governance tool.
Drift, conformance, and the weekly digest
A model this large will drift. New services land. Old ones get retired. Stacks shift — Falcor → GraphQL Federation, Reloaded → Cosmos, Hystrix → maintenance mode.
Archyl computes a drift score weekly: the gap between the documented C4 model and what's currently in the codebase. Conformance rules add the policy layer — "every container needs an owner team", "no cross-database access", "every ADR-marked technology must be in the radar".
For Netflix that's drift detection at the scale of a thousand services. But the rules are the same as for ten.
And the Architecture Team Digest we shipped last week would, in a Netflix-like setup, mean:
- Member Systems' Monday digest covers their twelve membership microservices
- Open Connect's digest covers the OCAs and control plane
- Streaming Algorithms' digest covers Cosmos and the encoding components
- Each digest scoped to its team's owned perimeter, in its team's timezone
Same surface. Different scopes. That's the symmetry C4 + ownership unlock.
You don't need a thousand services
You're not Netflix. Most engineering organizations aren't.
But the lesson scales down. The discipline of separating Context from Container from Component, of writing the ADR that explains the diagram, of attaching ownership to every box — that discipline is what keeps a stack of fifty services from feeling like a thousand.
C4 + ADRs + Ownership + Drift + Conformance is what Archyl gives you out of the box. The Netflix example is just the largest plausible stress-test of the model.
Open up your own architecture. Sketch ten systems. Pick the one that hurts the most, zoom into its containers. Write three ADRs explaining why the choices look the way they do. Map a team to every container.
You'll be ahead of where most engineering organizations get to in a year.
Want to model your own architecture in C4? Start with Archyl. Read more on why ADRs and C4 work better together or how Architecture Change Requests bring pull-request rigor to your C4 model.