System Design · Trade-offs · ~10 min read
Netflix: Trade-offs & Decisions
Every architectural decision in a streaming platform involves a trade-off. This section makes them explicit — the alternatives considered, the reason for each choice, and where different choices make sense.
Mangesh MandlikLast updated:
Trade-off 01
Origin-Only vs CDN Delivery
Why not just serve video directly from object storage to users?
Origin-only delivery
Simple. One place for content. No cache invalidation complexity. Works fine at small scale.
CDN delivery
Distributes content to hundreds of edge locations. Substantially reduces latency to the viewer (the factor depends on distance and network path). Reduces origin bandwidth cost dramatically. Required for global scale.
At small scale, origin-only is completely reasonable. At the scale of a global streaming service with very large numbers of concurrent viewers, a single-region origin cannot sustain the aggregate bandwidth. Physics (network round-trip times) alone make origin-only delivery unusable for a good streaming experience.
Trade-off 02
Quality vs Startup Latency
Should the player start at the highest available quality, or optimize for fast startup?
Starting at 4K means downloading a larger first segment before playback can begin — potentially seconds of startup time on a moderate connection. Starting at 480p means the first segment downloads quickly, playback starts immediately, and quality ramps up as bandwidth is established.
Trade-off 03
Pre-encoding vs On-demand Transcoding
Should all renditions be pre-encoded at upload time, or transcoded on first request?
Pre-encoding
All renditions exist in storage before any viewer requests them. Zero encoding latency at playback. Higher storage cost.
On-demand encoding
Transcode only the quality levels actually requested. Lower storage cost for rarely-watched content. Adds latency on first request.
For a major streaming platform, pre-encoding wins decisively. Storage is cheap. Transcoding-on-demand at the scale of millions of simultaneous first-time requests is operationally intractable. Pre-encoding also allows quality assurance before release.
Trade-off 04
Centralized vs Multi-region Control Plane
Should the control plane (auth, catalog, playback API) be in one region or multiple?
Single-region control plane
Simple to operate. Single source of truth. Fails globally if the region goes down.
Multi-region control plane
Resilient to regional failures. Lower latency for auth and catalog queries globally. Significantly more complex to operate — data consistency across regions is non-trivial.
The data plane (video bytes via CDN) is distributed by definition. The control plane can start centralized and be regionalized as operational maturity and scale justify it. A single-region control-plane outage is bad but recoverable; a data-plane (CDN) outage at global scale is existential.
Trade-off 05
Collaborative vs Content-Based vs Hybrid Recommendations
Which recommendation approach should the system lean on: pure collaborative filtering, pure content-based filtering, or a hybrid?
Pure collaborative filtering
Strong personalization once there's enough viewing history to work with. Cold-start problem for both new users (no history to collaborate from) and new titles (no engagement data yet).
Pure content-based filtering
Works immediately for any user or title — genre, cast, and metadata are known from day one. Personalization is weaker and more generic than an approach with real behavioral signal.
The two approaches fail at exactly opposite times: content-based works on day one but plateaus, collaborative gets stronger over time but is blind on day one. A hybrid — content-based as the cold-start fallback, shifting weight to collaborative and embedding-based signal as history accumulates — covers both failure modes without giving up either strength. See the full Recommendation System deep dive for how the signal pipeline and embeddings actually work.
Trade-off 06
Last-Write-Wins vs Conflict-Aware Sync for Watch State
When two devices race to update the same user's watch position, should the system resolve conflicts with simple last-write-wins, or something more conflict-aware?
Last-write-wins by timestamp
Simple, cheap, no coordination needed between writes. Risk: a stale write could theoretically overwrite a newer one if clocks or network delivery are out of order.
Conflict-aware sync (vector clocks, CRDTs, etc.)
Correctly resolves out-of-order or concurrent writes without losing information. Meaningfully more infrastructure and complexity to build and operate correctly.
This is the same 'two writes race for the same record' shape as Uber's driver-assignment problem — but the cost of being wrong is completely different. Double-assigning a driver is a costly, hard-to-undo failure that justifies atomic conditional writes. A resume point that's off by a few seconds costs the viewer a quick scrub and nothing else. The right consistency model follows from the cost of being wrong, not from the shape of the problem alone.