Skip to content

How a Netflix-like streaming service might evolve

Pressing play should start video in about a second, anywhere, on any device, and never stall. How encoding pipelines, edge caching, recommendations and deliberate failure testing shape a streaming architecture.

The user problem and the hard parts

The viewer wants three things: find something worth watching quickly, press play and see video almost instantly, and never see a spinner mid-episode. The service wants to do it for a monthly fee, which means bandwidth and encoding costs decide whether the business works.

The hard engineering problems:

  • Bytes, not requests: one hour of HD video is gigabytes. At peak evening hours a large streamer can be a double-digit share of a country's internet traffic. You cannot serve that from a few data centres.
  • Encoding: every title must exist in many versions (resolutions, bitrates, codecs, audio tracks, subtitles) so each device on each network gets the best stream it can sustain.
  • Adaptive playback: the player measures throughput and switches bitrate every few seconds. Video is cut into small segments so switching is seamless.
  • Discovery: a catalogue of thousands of titles, and most viewers choose from the first rows they see. Personalised ranking is the product.
  • Resilience: hundreds of services in the control plane. Some are always failing; playback must survive anyway.
Control plane
Everything before the first byte of video: sign-in, browsing, recommendations, licence and playback authorisation. Classic web services in the cloud.
Data plane
Delivering video segments. A problem: caches as close to the viewer as possible.
ABR · Adaptive Bitrate streaming
The player picks a quality per segment based on measured bandwidth and buffer level, using protocols like HLS (HTTP Live Streaming) or DASH (Dynamic Adaptive Streaming over HTTP).
DRM · Digital Rights Management
Segments are encrypted; the player fetches a licence key from a licence server before it can decode them. Studios require it.

How the architecture might evolve

A Netflix-like streaming service

A plausible architecture for a subscription video streaming service at each scale. Where Netflix has described something publicly (Open Connect, chaos engineering) it is labelled as such; everything else is illustrative.

  1. 1
    Stage 1 · Launch
    100k subscribers · 1k titles
    Web + TV appsMonolith API (catalogue, accounts, billing)PostgreSQLBatch encoding jobs on cloud VMsCommercial CDNObject storage for masters and encodes

    A commercial CDN gives global delivery on day one. Encoding is a batch job per title. The is fine because the control plane carries little traffic compared to video bytes.

  2. 2
    Stage 2 · Growth
    5M subscribers · peak 500k concurrent streams
    Parallel encoding pipeline (split title into chunks, encode in parallel)Per-device bitrate laddersRedis cache for catalogue and home rowsEvent stream of playback telemetryFirst recommendation models (batch)

    Encoding a film serially takes hours; chunked parallel encoding makes it minutes. Playback telemetry (start time, rebuffers, bitrate) becomes the main quality signal for both engineering and the CDN contract.

  3. 3
    Stage 3 · Global scale
    50M+ subscribers · millions of concurrent streams
    Own edge caches inside ISP networks (Netflix publicly describes this as Open Connect)Overnight proactive fill of popular titles to edgesMicroservices behind an API gatewayWide-column stores for viewing historyChaos engineering in production

    At this volume, bandwidth bought from a CDN is a dominant cost, and the best place for a cache is inside the viewer's ISP. Netflix has publicly described placing its own appliances there and filling them off-peak with predicted demand.

  4. 4
    Stage 4 · Personalisation platform
    Global · hundreds of services
    Real-time and batch recommendation pipelinesPer-title and per-scene encoding optimisationPersonalised artwork experimentsMulti-region active-active control planeLarge-scale A/B testing platform

    Gains now come from quality per bit (smarter encoding) and engagement per session (better ranking). Every change ships as an because intuition is a poor predictor of what millions of viewers do.

From upload to the living room

A plausible architecture for Stage 3 might look like this. Note the two very different paths: a small, chatty control plane and a huge, simple data plane.

Click a component

Click any component to see what it does.

Deep dive: designing for failure

With hundreds of services, something is always broken. Netflix has publicly described chaos engineering: deliberately terminating instances (the original "Chaos Monkey") and later whole zones or regions in production, to prove that the system survives.

The patterns that make that survivable:

  • Timeouts everywhere: a call without a timeout turns one slow dependency into exhausted threads in every caller. This is partial failure spreading.
  • Circuit breakers: after repeated failures, stop calling the dependency for a while and use a fallback.
  • Fallbacks that keep playback alive: stale recommendations, a default artwork, a cached entitlement check for a short window.
  • Bulkheads: separate thread pools or instances per dependency, so one bad service cannot consume all capacity.
  • Regional evacuation: services in several regions with replicated data, so traffic can be shifted away from a failing region.

Engineering trade-offs

Commercial CDN

  • Global reach on day one
  • No hardware or ISP relationships
  • Bandwidth cost grows linearly with viewing
  • Less control over cache behaviour and routing
Choose when: Until video delivery is a dominant line in the cost structure.

Own edge appliances in ISPs

  • Much lower marginal cost per GB at huge scale
  • Better quality: bytes travel fewer hops
  • ISPs save transit costs, so they cooperate
  • Hardware, logistics and peering teams
  • Years to build
  • Only pays off at very large volume
Choose when: You are a significant share of internet traffic in many countries.

Fewer, higher-quality encodes

  • Lower storage and encoding cost
  • Viewers on weak networks rebuffer or get poor quality
Choose when: Small catalogue with a homogeneous audience.

Rich per-title bitrate ladders

  • Better quality per bit, lower bandwidth bill
  • Better experience on weak networks
  • Large encoding compute and storage cost per title
Choose when: Each title is watched by millions, so encoding cost is amortised.

Practical exercise

Premiere night

A hugely anticipated season drops worldwide at 08:00 UTC. You expect 10 million streams in the first hour. What could fail, and how would you prepare the data plane and the control plane?