Video Streaming

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

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.

Mechanism reference

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

View full sizeOpen original

Video Streaming: worked example

Reset viewClose

Video Streaming: connect a named mechanism to the requirement and an exact exercise trace.

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

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

View full sizeOpen original

Start playback: control first, media next

Reset viewClose

Authorization and large-byte delivery have different owners and scaling pressures.

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

View full sizeOpen original

Can the next segment arrive before the buffer empties?

Reset viewClose

Explain the throughput-to-buffer decision using actual segment quantities.

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

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?

Question: A session was authorized before a rights change. Can it play forever?

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

View full sizeOpen original

Video Streaming: worked example

Reset viewClose

Video Streaming: a concrete state and recovery trace under the exercise assumptions.

If a rights grant expires during playback, does the CDN automatically know the next segment must be denied?

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.