Media & streaming, an interactive architecture walkthrough
Netflix-style video streaming: how the architecture works
How a streaming service encodes each title into many bitrates, caches it near viewers on a CDN, and personalises what each person sees.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A streaming service has two halves. A content pipeline turns each master file into many resolution and bitrate versions packaged for adaptive streaming, and a delivery network caches those segments close to viewers. Around them, microservices handle accounts, search, entitlement and DRM, while playback telemetry flows through a collector into Kafka and feeds the recommendation models. This is a generic reference design, not Netflix's internal architecture.
Trade-offs and what changes at scale
Encoding every title at many bitrates and codecs costs compute and storage, which is worth it because each title is watched far more often than it is encoded; tuning the ladder per title cuts bandwidth further. Pre-filling popular titles on ISP appliances off-peak keeps peak-hour traffic off the internet backbone, but titles an appliance does not hold are fetched from peer appliances, a regional tier or origin, so cache hit ratio at the edge is the number to watch. Home-screen rows are precomputed and cached so a training delay degrades freshness, not availability. At scale, playback telemetry is sampled or batched, and the control plane (entitlement, DRM licences, steering) must stay up even when parts of the catalogue or recommendations do not.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
A studio uploads a high-quality master to object storage. Keeping the untouched source lets us re-encode later for new codecs without going back to the studio.
The splitter cuts the master into chunks so many workers encode resolution, bitrate and codec ladders in parallel. A failed chunk is retried alone, not the whole title.
The packager assembles encoded chunks into HLS/DASH segments and manifests, applies encryption, and stores them in origin storage. The content keys go to the DRM licence server, which issues licences against them later.
Packaging emits a title-ready event, so the catalog marks the title available and updates the search index. Nothing is visible to users until assets exist.
A fill controller tells the appliances what to hold, and they fetch it ahead of demand during an off-peak window, so viewers are served close to home and upstream traffic stays low. If an appliance lacks a file, it can fill it from a peer appliance, a regional tier or origin (details vary by operator).
A user opens the TV app. The gateway validates the token locally against cached signing keys (the identity service is for login and revocation), then recommendation serving reads precomputed rows from the cache, so the home screen stays fast even if training lags.
Profile data picks the active profile, while viewing history from Cassandra personalises and filters rows, such as hiding watched titles. Catalog supplies titles and artwork.
Typing a query goes through the gateway to the search service, which queries Elasticsearch. A dedicated index gives fast fuzzy matching without loading the catalog database.
On Play, the playback service checks the plan and device limits and returns a manifest plus a short-lived playback token. The player (on any device) then requests a licence from the DRM licence server itself, which looks up the entitlement before issuing it. Failed entitlement means no stream.
Billing owns subscription state in a relational database for transactional safety and charges cards through an external payment provider. A renewal job triggers the recurring charge, and the provider reports the outcome by webhook; a failed renewal updates the plan state. Billing keeps the plan in the account service up to date, which is what the playback check reads, so billing is not in the play request path.
Appliances report their health, routes and what they have cached to the control plane (shown here as the steering service), which ranks CDN nodes using client location, node health and cached content, and returns the best URLs. The client then fetches adaptive bitrate segments, switching quality with bandwidth.
Players send telemetry such as start, pause and errors through the gateway to a collector, which batches it and publishes to Kafka; clients never write to Kafka directly. The playback service publishes its own events too.
A consumer of the stream writes viewing history and bookmarks into Cassandra; this is the only writer of bookmarks. The playback service only reads them to resume.
Events are archived in the data lake, analytics jobs (for example Spark) build features, and offline training retrains the models. Fresh rows are published to the cache, closing the personalisation loop.
Metrics from the gateway, playback, encoders, edges and the stream feed observability, so on-call can spot rebuffering, encode backlogs or failing nodes quickly.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (35 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Content Pipelinedomain
- Chunk Splitter: splits video into chunks
- Encoding Workers: parallel bitrate/codec ladders
- Master Files: source masters
- Origin Storage: encoded segments, manifests
- Packager: HLS/DASH packaging, encryption
- Studio Upload: content partners
Backend Microservicesdomain
- Account & Profile: users, profiles, devices
- Billing Service: subscriptions, invoices
- Catalog & Metadata: titles, artwork, availability
- DRM Licence Server: issues licences to entitled players
- Playback Service: entitlement, manifest, playback token
- Recommendation Serving: personalised rows, online
- Renewal Scheduler: triggers subscription renewals
- Search Service: query and suggestions
- Steering Service: picks best CDN node
- Telemetry Collector: batches client events, publishes to Kafka
Operational Data Storeslayer
- Billing DB: subscriptions, invoices (postgresql)
- Catalog DB: title metadata (mysql)
- Reco Cache: precomputed rows
- Search Index: title search index (elasticsearch)
- Viewing History: watch history, bookmarks (cassandra)
Content Deliverydomain
- Edge Appliances in ISPs: cache video segments
- Fill Controller: tells edges what to hold, off-peak
- Regional Cache Tier: fills ISP appliances on a miss
API Gateway
- API Gateway: routing, authn, rate limits
Client Appslayer
- Mobile App: iOS and Android
- TV App: smart TV and set-top box
- Web App: browser player
Identity & Tokens
- Identity & Tokens: sessions, JWT issuance
Payment Provider
- Payment Provider: card processing
Data & MLlayer
- Analytics Jobs: ETL, feature building
- Data Lake: raw events and features
- Model Training: offline recommendation training
- Playback Event Stream: play, pause, errors, QoE (kafka)
Observability
- Observability: metrics, logs, traces
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Video sharing platform (YouTube-style)How a video platform takes resumable uploads, encodes segments in parallel into several renditions, and serves them via a CDN with adaptive bitrate.
- Music streaming serviceHow a music streaming service pre-encodes tracks into encrypted segments, checks rights before playback, and turns play events into royalties.
- Photo sharing platformHow a photo sharing platform takes uploads straight to object storage, resizes them in the background, and builds follower feeds from cached post ids.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.