Video Streaming
Design Netflix or Prime Video on-demand playback: ingestion, manifests, adaptive bitrate, CDN, rights and recovery.
Video Streaming: Understand the building blocks
Choose a mechanism because it satisfies a requirement. These explanations describe the exercise design, not undisclosed implementation choices at the named company.
Video Streaming: Quick vocabulary
| Term | Meaning and role in this exercise |
|---|---|
| API: Application Programming Interface | The contract for requests, responses and errors between components. An API route does not itself enforce every business invariant. |
Video Streaming: Content Delivery Network (CDN)
What it means: A CDN serves cacheable content from distributed locations nearer viewers, reducing repeated origin reads and network distance.
Why this problem needs it: Netflix-style on-demand playback repeatedly serves large shared media bytes.
How to use it: Use stable versioned media URLs, a bounded cache policy, and the agreed signed-access or entitlement checks. Plan cold-cache and miss admission at the origin.
Example in this design: The catalog/session API authorizes while the CDN/origin path supplies segments.
When it fits: Useful when many geographically distributed users fetch the same media bytes.
Alternative and limits: Direct object storage/origin delivery can fit a small workload. A CDN neither transcodes media nor independently knows every rights change.
Video Streaming: Transcoding and a dependency graph
What it means: Transcoding converts input media into required encoded outputs. A dependency graph records which validation/encoding/packaging steps must finish before publication.
Why this problem needs it: One title needs compatible renditions before release.
How to use it: Create versioned jobs for required renditions, bound compute concurrency, retry failed attempts safely, and mark the manifest ready only after required outputs are verified.
Example in this design: Verify required outputs before exposing a ready manifest.
When it fits: Useful when uploads must play on different devices or at multiple bandwidth levels.
Alternative and limits: Serving an already compatible source can be a simpler baseline. A completed task does not imply all outputs or a newer input generation are ready.
Video Streaming: Adaptive Bitrate (ABR), renditions and segments
What it means: A rendition is an encoded bitrate/resolution version; a segment is a short time interval of media. ABR selects a suitable rendition for upcoming intervals.
Why this problem needs it: The player must react to changing bandwidth.
How to use it: Estimate throughput and buffer health; switch only at compatible aligned boundaries. The manifest identifies available versions and segments.
Example in this design: Six seconds at 3 Mbps is 18 Mbit; 1.5 Mbps throughput takes 12 seconds, exceeding an eight-second buffer.
When it fits: Useful when viewer bandwidth changes and the player must trade picture quality against stalls.
Alternative and limits: A fixed rendition is simpler but may stall or waste bandwidth. ABR cannot fix missing segments or incompatible encodings.
Video Streaming: HTTP Live Streaming (HLS), DASH and manifests
What it means: HLS distributes media through HTTP playlists and segment requests. DASH means Dynamic Adaptive Streaming over HTTP and uses its own presentation description; they are packaging/player protocol choices.
Why this problem needs it: Manifest and segment packaging must match the intended player/device set.
How to use it: Prepare compatible renditions and manifest entries, publish references only to verified media, and configure live-playlist freshness for the latency contract.
Example in this design: Switch to an aligned lower-bitrate rendition without changing playback time.
When it fits: Useful when supported players should fetch adaptive media through HTTP caches.
Alternative and limits: Select the protocol by device support, latency and media protection requirements. A manifest is an index of media, not the video bytes or a rights decision.
Video Streaming: Digital Rights Management (DRM) and playback entitlement
What it means: Entitlement is the application’s decision that an account may watch; DRM controls protected media/key use through compatible playback and licensing mechanisms.
Why this problem needs it: Licensed content may need controlled key use in addition to media URLs.
How to use it: Authorize a playback session and the supported license/key path, set expiry/revocation policies, and protect sensitive credentials.
Example in this design: A playback session and supported license path independently enforce the stated entitlement policy.
When it fits: Useful when content licensing requires controlled protected playback.
Alternative and limits: Signed media URLs can restrict fetches but are not equivalent to DRM. Neither mechanism guarantees that all capture or copying is impossible.
Read the diagram
CDN supplies shared segments; API authorizes playback; Six seconds at 3 Mbps contains 18 Mbit; At 1.5 Mbps download takes 12 seconds: stall risk; ABR can choose 1 Mbps: download takes 4 seconds
Understand the playback problem
For “design Netflix” or “design Prime Video,” ask whether the interviewer wants on-demand playback, a content catalog, recommendations, subscriptions or live sports. This lesson designs an original on-demand service: authorized viewers choose a published title and play it across varying networks. Content is supplied by a controlled publishing pipeline. User-generated upload and live ingest have different control and latency requirements; compare YouTube and Live Video Streaming. Product names describe exercises, not actual company architectures.
A rendition is an encoded version at a particular bitrate/resolution. A segment is a short media chunk. A manifest tells the player which renditions/segments exist. Adaptive bitrate playback changes the next segment's rendition using measured throughput and buffer health. A CDN caches media near viewers; it does not decide whether an account is entitled to watch a title.
Clarify before drawing
| Ask the interviewer | Assumption for this exercise | What changes if the answer differs |
|---|---|---|
| Playback, recommendations or billing first? | Catalog selection and playback | Recommendation ranking/billing need separate state and correctness contracts |
| On-demand or live? | Immutable on-demand media | Live manifests advance under a latency budget |
| Content providers or arbitrary user uploads? | Controlled licensed-content ingestion | Public uploads require abuse checks and uploader lifecycle |
| Devices, codecs, languages and accessibility? | Web/mobile/TV, several renditions, captions and alternative audio | Encoding ladder, device compatibility and publishing completeness change |
| Concurrent viewers, popular-title skew and quality? | One million concurrent viewers, 3 Mbps mean video bitrate | Egress and cache placement dominate different cost regimes |
| Startup/rebuffer target and allowed degradation? | Illustrative p95 start under 2 seconds and rebuffer ratio under 1% for supported networks | More startup buffer trades latency for fewer stalls; targets require measurement |
| Entitlement, geographic rights and offline downloads? | Online playback with title/region policy; downloads excluded | License lifetime, revocation and offline storage become additional boundaries |
| Regional failure and cost ceiling? | Media served through CDN; control-plane failover with bounded session policy | Multi-region ownership and delivery alternatives need explicit trade-offs |
Start: “I’ll design choosing and playing a published title, including rights checks and adaptive delivery. I’ll keep billing and recommendations outside the first design. Shall I use one million concurrent viewers as the peak assumption?” Confirm instead of silently importing every product feature.
Estimate what changes the design
One million viewers × 3 Mbps = 3 Tbps of encoded media delivery, before overhead. A two-hour title at 3 Mbps is 2.7 GB in decimal units. A six-second segment at that rate is 2.25 MB. At 10,000 playback starts/s, the session API is much smaller in bytes than the media path but still needs admission, authorization and license capacity. Distinguish media bandwidth, request rate and concurrent users.
Do not size the origin for the average CDN hit ratio alone. A new popular title, cache eviction or failover can create an origin burst. Preposition likely popular renditions where justified, protect the origin with a shield/coalescing tier, and cap misses. Keep an explicit cost model: delivered GB, origin GB, stored renditions, transcode compute and license/control requests.
Model publishing and sessions
titles(title_id,metadata,rights_policy_version,published_generation)
assets(title_id,generation,rendition_id,segment_index,immutable_key,checksum)
publications(title_id,generation,state,verified_manifest_key)
playback_sessions(session_id,user_id,title_id,rights_version,expiry,state)
watch_progress(user_id,profile_id,title_id,revision,position_seconds)Publishing is a conditional transition: generation g7 becomes playable only after every required referenced output passes validation and its rights policy is ready. Generation g6 remains a coherent version until the new pointer commits. A manifest must never mix segments from different source generations by accident. Store immutable media keys; update the metadata pointer atomically at its owner. Keep caption/audio accessibility requirements in the publication check, not as an afterthought.
GET /catalog?cursor=... -> bounded titles, nextCursor
POST /playback-sessions {titleId,deviceCapabilities,requestKey}
-> sessionId, authorizedManifestUrl, expiry, licenseConfiguration
GET /playback-sessions/{id} -> current state or explicit denial
PUT /profiles/{id}/progress {titleId,expectedRevision,positionSeconds}The session API authenticates the viewer, checks object/title entitlement and applicable region/device policy, and returns short-lived access under a declared lifetime. Do not cache an account-specific authorization response as a public catalog object. A cacheable manifest still needs access enforcement on the serving path. Define concurrency limits for sessions and how a crashed device releases its slot.
Separate control decisions from media delivery
Read the diagram
Viewer asks playback service for a title and device profile → Control path checks rights and published asset generation → Session returns a short-lived playback credential and manifest → Player reads the manifest; selects a compatible rendition → Media path: CDN serves immutable segments; origin fills misses → Player adapts bitrate and sends quality telemetry separately
The first baseline has a catalog/session service, authoritative metadata/entitlement store, object storage for verified media, and CDN delivery. A publishing job prepares renditions and a verified manifest. The viewer obtains a session, fetches the manifest and then requests media segments. Explain a successful path before adding an elaborate service fleet. Add a job queue only for publishing work whose durable job identity and retry policy are explicit.
For protected content, a supported DRM/license system provides device-specific protected-media access. W3C Encrypted Media Extensions is a browser interface for interacting with key systems; it is not the license service or an access-control policy. Signed URLs alone do not provide equivalent content protection. Do not invent a proprietary encryption scheme during the interview; state the key/license boundary, expiry and supported device assumptions.
Walk through a player decision
At 3 Mbps, a six-second segment contains about 18 Mbit. If measured throughput falls to 1.5 Mbps, fetching it takes about 12 seconds before overhead. With only eight seconds buffered, continuing that rendition risks a stall. A 1 Mbps rendition of the same six-second interval is about 6 Mbit and takes about four seconds; it can refill the buffer under these illustrative conditions. Aligned switching points and device-compatible encodings are prerequisites, not consequences of a CDN.
Read the diagram
6-second segment at 3 Mbps = 18 Mbit → At 1.5 Mbps throughput, download takes 12 seconds → Only 8 seconds buffered: stall risk without adaptation → Choose 1 Mbps rendition: 6 Mbit downloads in 4 seconds → A completed 6-second segment replenishes playable buffer → Adapt using measured throughput and buffer; include overhead
The player considers recent throughput, buffer health and stability; one instantaneous sample can cause oscillation. Startup begins with a safe initial rendition and a limited buffer. Prefetch is bounded so a paused or abandoned session does not download a whole title. Retry failed segment delivery within a deadline; do not retry indefinitely while the buffer empties.
Test the failure boundaries
| Failure | User consequence | Design response |
|---|---|---|
| Publisher writes two renditions and crashes | Incomplete generation must not be offered | Resume under the same job/generation; validate before pointer publication |
| Session request commits but response is lost | Caller may create duplicate session slots | Stable request identity returns the existing session under its contract |
| Rights are revoked while a link is cached | Old cached bytes/links can outlive policy | Declare expiry/revalidation boundary; enforce at serving/license boundary |
| CDN region fails or misses surge | Origin overload and playback stalls | Bounded failover/routing, origin miss admission and measured player recovery |
| License service is slow | Media availability alone cannot start playback | Bound license concurrency/deadline; disclose permitted session-grace policy |
| Progress arrives out of order | Older device can overwrite later progress | Revision/device policy; state whether rewind is a legitimate newer action |
A playback progress value is not always a monotonically increasing maximum: a user can intentionally rewind. Define the desired cross-device conflict policy. Separate durable publishing truth from reconstructible catalog/search caches.
Explain the same answer at different levels
At foundation level, define manifests, draw session authorization and one segment read, and calculate a bitrate-to-byte estimate. At intermediate level, explain rendition switching, cache misses, request identities and stable media generations. At senior level, defend publication atomicity, rights boundaries, origin protection and user-level SLOs. At staff level, compare regional/CDN and encoding strategies against measured quality/cost, assign publishing/playback ownership, and describe a compatible staged rollout with a rollback gate.
A staff rollout can shadow manifest validation for a new codec, enable a small compatible device cohort, compare startup/rebuffer/decoding error and cost, then expand. Keep the previous codec/manifest generation available until rollback is safe. Avoid moving entitlement and media generation ownership simultaneously without independent checks.
Practice and evaluate
Try designing a two-hour title launch with a cold edge cache. Deliver a clarification list, requirements, bitrate worksheet, entity/API model, complete viewer path and two failure traces. Explain the difference between media being present and the viewer being authorized.
Question: Will adding ten session API instances solve 3 Tbps of media delivery?
Show answer and explanation
Answer: The session API handles control work. Media bandwidth belongs to the CDN/origin path. Capacity and failures must be measured separately.
Question: A session was authorized before a rights change. Can it play forever?
Show answer and explanation
Answer: Only if that is the explicitly agreed policy. Define token/license lifetime, revalidation and revocation behavior; indefinite cached grants are not an automatic consequence of signed URLs.
Primary documentation: HTTP Live Streaming, Apple HLS guidance and W3C Encrypted Media Extensions. The worked scale, player timing and architecture are independent exercise assumptions.
Decision review: Video Streaming
Video Streaming: What it is
An on-demand video design grants playback sessions and delivers compatible media within the player’s buffer constraints.
Video Streaming: Why it is needed
Control API success and media delivery success do not establish smooth playback or current viewing entitlement.
Video Streaming: When to use it
Use separate session/control and byte paths when repeated large media delivery dominates bandwidth; state device, codec and rights requirements.
Video Streaming: How to use it
Publish verified immutable renditions and a usable manifest, authorize the session, then adapt compatible segments using throughput and buffer observations. Control grant scope and expiry independently of cached bytes.
Video Streaming: Compare an alternative
A lower bitrate can reduce stalls at the cost of quality. A larger buffer reduces network sensitivity but increases startup or live delay; compare the actual experience target.
Video Streaming: Worked decision exercise
The following inputs and policies are original exercise assumptions; they are not measurements or undisclosed company behavior.
A six-second 3 Mbps segment has about 18 Mbit. At 1.5 Mbps it needs 12 seconds before overhead. With eight seconds buffered, switching to a compatible 1 Mbps segment can reduce transfer to about four seconds.
Read the diagram
6 seconds x 3 Mbps = 18 Mbit; At 1.5 Mbps download takes about 12 seconds; Only 8 seconds buffered: high rendition risks stall; At 1 Mbps the 6 Mbit segment takes about 4 seconds
If a rights grant expires during playback, does the CDN automatically know the next segment must be denied?
Show answer and explanation
Answer: Only if the delivery authorization design enforces that policy. Describe signed-capability lifetime or a current check, how in-flight requests behave, and bytes already received. A cached segment is not an entitlement authority.
Video Streaming: Check the design
Monitor startup, rebuffering, playback failure, authorization and origin load separately. Test codec/rendition compatibility and a missing object referenced by a manifest.