Netflix

Assume 300M subscribers, 120M daily active viewers, and 40M peak concurrent streams during prime time and major releases. Average delivered bitrate across mobile, HD, and 4K sessions is 5 Mbps, while high-end 4K sessions can exceed 15 Mbps.

Assume 250K hours of watchable catalog after including movies, episodes, trailers, dubs, and regional variants. If one catalog hour produces about 80 GB across H.264, HEVC, AV1, multiple resolutions, audio tracks, subtitles, thumbnails, manifests, and packaging overhead, the encoded origin catalog is about 20 PB before replication. With three durable copies plus metadata and staging assets, plan for 60 PB or more at origin.

A playback client downloads segments in small chunks, commonly 2 to 6 seconds each. With 40M concurrent streams and one segment request every 4 seconds, the CDN sees about 10M segment requests per second at peak, plus manifest refreshes, subtitle fetches, and telemetry.

• Peak egress: 40M concurrent streams times 5 Mbps is 200M Mbps, which is 200 Tbps before TLS, TCP, and retry overhead. A real platform reserves substantial headroom because major releases and sports-like events create correlated demand.
• Segment requests: if each player fetches a segment every 4 seconds, 40M concurrent players divided by 4 seconds is 10M segment requests per second. This traffic must terminate at CDN edge caches, not at the cloud APIs.
• Catalog storage: 250K catalog hours times 80 GB per encoded hour is 20,000,000 GB, or about 20 PB. Three durable copies make this about 60 PB before indexes, previews, artwork, and temporary encoding outputs.
• CDN footprint: the hottest 20 percent of regional titles may drive 80 percent of streaming. Keeping 5 to 10 PB of hot assets inside ISP edge caches can remove most origin traffic while allowing long-tail titles to fill on demand.
• Telemetry: 40M players sending one to two QoE events per minute means 40M to 80M events per minute, or roughly 667K to 1.33M events per second. This belongs in a streaming pipeline, not a synchronous playback API.
• Control plane load: playback starts are much lower than segment traffic. If 120M daily viewers start three sessions each, that is 360M playback starts per day, or about 4,200 starts per second on average. A 20x peak gives about 84K starts per second, which is large but manageable with stateless APIs and caches.

• catalog_titles.title_id is the primary key for detail pages and playback checks.
• catalog_titles.available_regions should be indexed or pre-materialized by region because availability filtering is frequent.
• encoded_assets.title_id, codec, device_profile selects the right ABR ladder at playback start.
• playback_sessions.playback_session_id supports DRM license checks and telemetry correlation.
• viewing_history.profile_id, last_played_at powers continue-watching rows without scanning a profile's full history.

A catalog title can have many encoded assets because each title may be packaged for several codecs, devices, bitrates, audio languages, subtitles, and DRM key sets. A playback session references one profile, one playable title, one selected asset family, and one initial edge server. Viewing history is keyed by profile and title so multiple devices converge on one resume position.

Use document stores or wide-column stores for localized catalog documents, regional availability snapshots, and profile viewing history. Use object storage for encoded media segments. Use a streaming platform for telemetry and watch events. Use an analytical warehouse or feature store for recommendation features and ranking outputs.

For playback session state, a low-latency replicated key-value store is usually better than a relational database because license checks and telemetry correlation are point lookups by session id. The exact product can vary, but the principle is to keep the video-serving data path independent from catalog joins and recommendation scoring.

The most important architectural split is that cloud APIs decide whether and how a user may play a title, while CDN caches deliver the bytes. The control plane includes authentication, catalog, recommendations, playback session creation, steering, DRM, history, telemetry intake, cache placement decisions, and operational dashboards.

The data plane is the high-bandwidth path from edge cache to player. At 40M concurrent streams and a 5 Mbps blended bitrate, the data plane carries about 200 Tbps. Putting this through application servers would be financially and operationally impossible. Instead, the Playback API returns signed edge URLs and then gets out of the way.

This split also changes failure behavior. If recommendations are down, the client can show cached rows. If telemetry intake is down, playback can continue. If the selected edge is down, steering or the player can fail over to another edge. Only entitlement, DRM, and manifest authorization are truly blocking at start time.

A naive system would encode every title into the same fixed ladder, such as 240p through 4K at predetermined bitrates. That wastes bandwidth on simple animation and underserves visually complex content. A premium design uses per-title and often per-scene analysis to choose bitrates that hit quality targets for each title.

The farm starts from mezzanine assets, runs complexity analysis, selects codec families such as H.264, HEVC, and AV1, creates ladders for device classes, packages DASH or HLS segments, encrypts content, generates subtitles and audio variants, and validates artifacts. Outputs are immutable versioned assets so cache keys and manifests remain stable.

The tradeoff is storage and compute. More ladders improve quality and device coverage, but they multiply origin storage and cache footprint. The design should keep enough variants for major device and network classes, then rely on ABR switching to adapt within each ladder rather than generating every possible combination.

Open Connect style caching places appliances inside or near ISP networks. Rather than waiting for users to request a new release and stampede origin, the control system predicts demand and pushes likely hot titles to the right regions ahead of time.

Placement uses signals such as release calendar, regional popularity, language, device mix, trending velocity, historical rewatch patterns, marketing campaigns, and available edge disk. Caches keep complete segment ranges for hot titles and partial ranges for medium-demand titles. Long-tail misses are filled from origin or upstream caches.

This reduces latency and cost, but it creates cache allocation tradeoffs. A title may be hot globally but unavailable in some regions due to licensing. A new release may need aggressive prefill even before there is watch history. Cache churn must be controlled so pre-positioning one title does not evict other high-value assets.

The steering API should not simply choose the geographically nearest server. It considers ISP, autonomous system, edge health, cache residency, live throughput, packet loss, historical QoE by device class, regional rights, token scope, and failover policy.

At session creation, the API can return a primary edge and backup choices through manifest URLs or DNS-style indirection. If the player sees repeated segment failures or poor throughput, it can request a refreshed manifest or switch to alternate hosts if the manifest permits it.

The key tradeoff is stability versus optimization. Aggressively moving players between edges may improve short-term throughput but can destroy cache locality and cause visible stalls. A good answer uses hysteresis, health thresholds, canaries, and QoE feedback loops rather than per-segment centralized steering.

The server publishes multiple renditions, but the player chooses the next segment. It estimates available bandwidth, buffer depth, decode performance, dropped frames, startup phase, device constraints, and viewport resolution. It starts conservatively to reach first frame quickly, then ramps quality when confidence increases.

ABR algorithms must avoid oscillation. If a player jumps to 4K after one fast segment and then immediately falls back, users see quality shifts and rebuffering. Practical players use smoothed throughput, buffer-based rules, safety margins, and caps from the manifest and device.

Client telemetry closes the loop. Rebuffer rate, startup delay, bitrate distribution, and failed segment requests tell the platform whether an edge is unhealthy, a ladder is too aggressive, or a device profile is wrong. This telemetry should influence future steering and encoding decisions, not block current playback.

The catalog service answers what can be shown and played: title hierarchy, artwork, metadata, localization, maturity ratings, and regional license windows. The recommendation system answers what should be shown first for a profile and context. These must be connected but separately scalable.

Viewing history is a critical bridge. Resume position powers continue-watching, completion feeds satisfaction features, recent watches affect ranking, and explicit feedback adjusts personalization. Writes are frequent and may arrive out of order from multiple devices, so use version timestamps, idempotent updates, and profile-partitioned storage.

Ranking should be precomputed or nearline for most rows. The online request path can blend cached personalized rows, fresh continue-watching, regional trends, editorial campaigns, and fallback popularity. Scoring the full catalog synchronously for every home request is too slow and too costly.

Streaming rights vary by country, time window, device type, subscription plan, maturity rules, and studio contract. The playback API must enforce these rules before returning a playable manifest. The catalog may hide unavailable titles earlier, but playback authorization remains the source of truth.

DRM protects encrypted content keys. The player obtains a license after proving device capability and referencing an authorized playback session. Licenses should be short-lived, scoped to the title and key ids, and renewable during long sessions. Key material should be isolated from general application services.

The tradeoff is latency and strictness. Overly chatty DRM flows hurt startup time, but weak enforcement risks contract violations. Cache safe entitlement decisions for a short time, sign manifests and segments with bounded expiry, and fail closed for premium content when license validation is uncertain.

Alternative one is to rely entirely on a third-party CDN. This is faster to launch and simpler operationally, but it gives less control over ISP placement, cache prefill, cost, and playback telemetry feedback.

Alternative two is to stream through application servers. This is acceptable only for a prototype or tiny catalog because application servers would become the video data plane and collapse under terabits of egress.

Alternative three is to use one fixed encoding ladder for all titles and devices. It reduces encoding complexity but wastes bandwidth on easy-to-encode titles and lowers quality for complex titles.

Do not build this full architecture for a small internal training video portal, a low-traffic course site, or an app with a tiny catalog. Use object storage, a managed CDN, simple encoding presets, and basic access tokens until bandwidth, device diversity, rights complexity, and personalization justify the added machinery.