Live Video Streaming
Design Hotstar or Prime Video live sports: live latency, kickoff traffic, DVR, publisher fencing and multi-CDN recovery.
Live 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.
Live 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. |
| TTL: Time to Live | An entry/grant lifetime. Logical expiry, physical cleanup and urgent revocation are distinct conditions. |
Live 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: Live playback needs continually updated media availability and freshness.
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: A player follows a bounded moving playlist rather than waiting for a finished file.
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.
Live 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: Viewers still need compatible quality adaptation.
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: Switch aligned segments while observing the declared live-edge buffer budget.
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.
Live 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: Kickoff can create a large synchronized delivery burst.
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: Protect the origin when edges miss the first live 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.
Live Video Streaming: Lease, ownership epoch and fencing
What it means: A lease grants temporary work ownership. A fencing token or epoch identifies a newer owner so stale owners can be rejected at the mutation boundary.
Why this problem needs it: Publisher failover must not produce overlapping incompatible timelines.
How to use it: Claim a job under an atomic authority, increment its attempt/epoch, and require that value on result publication. The protected resource must enforce the check.
Example in this design: Epoch 10 fences epoch 9 before accepting sequence 501 under the new owner.
When it fits: Useful when workers can pause, restart or overlap after a timeout.
Alternative and limits: A non-expiring lock risks blocking forever. Lease expiry alone cannot stop an old process that resumes; external effects need their own supported idempotency/reconciliation.
Live 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: Live rights and DVR availability have explicit expiry requirements.
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: An expired session follows the required license/media denial policy; a stale playlist is not permission.
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.
Live sports is a distinct design problem
“Design Hotstar” or “design Prime Video sports” may mean live delivery to a large audience watching the same event. Ask whether the focus is low-latency viewing, interaction, advertising, DVR or on-demand replay. This original lesson focuses on one live event, authorized playback, a bounded DVR window and recovery after an ingest failure. It does not claim to describe any company's implementation.
Glass-to-glass latency is time from captured action to its presentation on the viewer's screen. Ingest receives the contribution feed. An encoder creates playable renditions; a packager creates segments/manifests. The live edge is the newest playable media point. A viewer can intentionally stay behind that edge to absorb jitter; smaller buffers and shorter publishing units affect both latency and delivery resilience.
Ask which trade-off the interviewer wants
| Clarification | Exercise assumption | Why it changes the design |
|---|---|---|
| Live, on-demand or both? | Live first; later replay is an extension | A live manifest changes while an on-demand publication is finite |
| Required glass-to-glass latency? | Illustrative 8-second target | Sub-second interactivity requires a different transport/buffer trade-off |
| Concurrent viewers at kickoff? | Five million at 4 Mbps mean bitrate | Common arrival time and hot media keys stress delivery and session services |
| Are chat, betting or synchronized interactions included? | Excluded from core media path | Interaction timing, consistency and safety need independent contracts |
| DVR and seeking window? | 30 minutes, supported devices only | Retention, live versus historical manifests and expiry behavior change |
| Rights, DRM, geography and concurrent-device limits? | Online protected playback with explicit session policy | License/session admission can bottleneck before segment delivery |
| Feed and region failures? | Redundant contribution feeds; bounded failover gap | Encoders/packagers must preserve a coherent timeline |
| Advertising and captions? | Captions required; ad insertion is an extension | Timing alignment, personalized manifests and cacheability change |
Give a clear opening: “I'll prioritize authorized live playback and a 30-minute rewind window. I’ll separate media delivery from chat and define how the player reacts to a gap. Is latency or resilience the higher priority if they conflict?”
Budget latency and capacity before drawing
An illustrative eight-second budget allocates 1 second capture/ingest, 2 seconds encode/package, 1 second distribution and 4 seconds player buffer. Actual behavior must be measured on supported devices and networks; these allocations are not a protocol guarantee. Shorter segments/parts can lower publishing delay but increase request rate and reduce buffering margin. Do not promise low latency merely by adding WebSockets to a video service.
Five million viewers × 4 Mbps = 20 Tbps before overhead. If an uncached control decision is required for each of five million viewers over 60 seconds, the average join rate is about 83,333/s; a shorter kickoff burst is higher. At four-second segments, each viewer requests roughly 0.25 video segments/s, or 1.25 million segment requests/s before audio, manifests, retries and partial-segment requests. CDN cache effectiveness and origin protection are necessary, but authorization/manifest/license fanout also needs separate admission and capacity.
Read the diagram
Capture + contribution: 1 second from venue → Encode + package: 2 seconds to publish media → Distribution: 1 second through origin and edge → Player buffer: 4 seconds before displaying the frame → Total: 1 + 2 + 1 + 4 = 8 seconds → Lower buffering trades delay for a higher stall risk
Build an end-to-end baseline
events(event_id,state,rights_policy_version,active_generation)
media_units(event_id,generation,rendition,sequence,immutable_key,checksum)
playlists(event_id,generation,revision,first_sequence,last_sequence)
sessions(session_id,user_id,event_id,expiry,rights_version)
ingest_attempts(event_id,source_id,lease_epoch,status)POST /events/{id}/playback-sessions {device,requestKey}
-> sessionId, manifestUrl, expiry, licenseConfiguration
GET manifest -> moving live window and compatible renditions
GET media unit -> immutable bytes under authorized delivery policy
GET /events/{id}/state -> live, interrupted, endedThe contribution feed reaches a current ingest/packaging owner. It produces aligned renditions and verified immutable media units, then advances the playlist at its authority. Sessions verify current entitlement under the chosen policy. The CDN serves media and bounded-freshness playlists from a protected origin. The player measures buffer/throughput and reports user-visible quality. Keep the baseline complete before adding multiple CDN providers or regions.
Read the diagram
Session API admits viewer; checks entitlement and concurrency → Encoder sends aligned media to the fenced active packager → Packager publishes immutable media units before playlist references → Origin/CDN serve a briefly cached, mutable live playlist → Player fetches referenced immutable units and tracks live edge → DVR retains eligible old media; authorization limits seeking
A playlist is mutable and freshness-sensitive; segment bytes are immutable and can have a much longer cache lifetime. Do not apply the same TTL to both. A 30-minute DVR window makes older media addressable under an explicit retention policy. A requested sequence older than retention gets an explicit expired-window outcome or a permitted reset to an available point, not silent fabrication of missing media.
Recover an ingest failure without two current writers
Suppose packaging epoch 9 publishes through sequence 501. Its worker pauses. Epoch 10 takes ownership, validates a new contribution feed and prepares the next coherent timeline. The publication owner rejects late epoch-9 writes. If media timestamps/encoding continuity cannot be preserved, publish an explicit discontinuity compatible with the selected protocol/player behavior. A larger epoch is an ownership rule; it does not automatically align timestamps, audio or keyframes.
Read the diagram
Epoch 9 is active; it publishes media sequence 501 → Coordinator promotes standby with newer publisher epoch 10 → Epoch 10 validates timeline, media and a decodable boundary → Publication owner accepts epoch 10 conditionally → Late epoch 9 output is rejected by the publication destination → Playlist signals discontinuity when timelines cannot align
The viewer with sequence 499 obtains the current playlist and follows the declared gap policy. Retry within the remaining buffer/deadline; after a discontinuity, recover at a compatible independent point. Measure stall duration and distance from the live edge. Falling behind is different from having no playable media. Test captions and audio alignment after source switching as well as the visual frame.
Handle a common audience burst
Preposition configuration and applicable media, coalesce safe origin reads, and warm capacity before the event. Cap session and license work; define what queued/deferred/denied callers see. Retry with jitter and a total deadline so every viewer does not hit the origin at once. Cache only safely shareable representations: a personalized rights/ad manifest is not a universally cacheable response.
If a CDN provider or region is impaired, routing can move traffic, but the alternative must have enough headroom and compatible authorization/manifest behavior. Failover to an unwarmed origin can worsen the incident. Bound rerouting, monitor both quality and origin saturation, and preserve a reversal criterion. Continuing already authorized playback during a control-plane outage is an explicit rights/security decision with a lifetime, not an assumed universal grace period.
Operate from the viewer's experience
Track join/startup time, failed starts, rebuffer ratio, playback error, live-edge distance and audio/caption alignment by device, region, network and rendition. Separate ingest/encode/package age from CDN response success. A 200 response carrying an obsolete live manifest is still a bad user outcome.
The runbook distinguishes source loss, packaging lag, license overload, CDN failure and a device codec issue. Each has a different safe mitigation. Observe admitted concurrency, queue age, origin misses, license latency and delivery GB. Event rehearsal includes kickoff burst, stale packager, lost feed, cache miss storm and expired DVR requests. An event ending should transition publication and archive retention under a clear policy.
Adapt the answer to the role
Foundation: define live edge and a latency budget, draw a complete producer-to-player path and explain a stale playlist. Intermediate: separate mutable playlist caching from immutable segments, estimate the burst, and reason about buffering. Senior: defend fencing, synchronized retries, authorization, overload and viewer SLOs. Staff: compare latency/resilience/cost strategies, plan event rehearsal and capacity contracts across teams/providers, then stage a rollout with measured quality and a reversible routing policy.
Practice and follow-up
Deliver the clarification table, latency/traffic estimates, publication and session state, a complete baseline and an epoch-9/10 recovery trace. For staff depth, assume a provider can serve only half the required peak and explain an incremental capacity/routing decision.
Question: Does a 30-minute DVR window mean the live manifest should be cached for 30 minutes?
Show answer and explanation
Answer: No. Retention makes historical media available; a live playlist must advance under its freshness budget. They are different lifetimes.
Question: Can chat messages synchronize all viewers to the same sporting action?
Show answer and explanation
Answer: Not without an explicit synchronization model. Devices have different media latency and clocks. Interaction must reference an event/timeline position and account for viewer delay; excluding chat from the initial playback design keeps this separate requirement visible.
Primary documentation: HLS live playlist responsibilities, Apple streaming guidance and Encrypted Media Extensions. Budgets and failover records are original exercise assumptions.
Decision review: Live Video Streaming
Live Video Streaming: What it is
A live streaming design publishes a current media timeline while balancing end-to-end delay, playback continuity and audience bursts.
Live Video Streaming: Why it is needed
Redundant ingest is insufficient if two packagers publish conflicting timelines, and reducing buffer can increase stalls.
Live Video Streaming: When to use it
Use explicit glass-to-glass budgets and fenced publication ownership when a live feed can fail over between publishers.
Live Video Streaming: How to use it
Align required rendition/timeline boundaries, publish media before playlist references, condition the current publisher epoch at the destination and signal discontinuity where seamless continuation is not available.
Live Video Streaming: Compare an alternative
Lower latency often spends resilience to jitter. A wider delay budget may permit buffering and simpler distribution; the correct choice depends on synchronized viewing, DVR and stall targets.
Live Video Streaming: Worked decision exercise
The following inputs and policies are original exercise assumptions; they are not measurements or undisclosed company behavior.
Publisher epoch 9 emitted sequence 501. Epoch 10 takes over after validating a decodable continuation. A late epoch 9 playlist write must be rejected. An illustrative latency budget of 1+2+1+4 seconds totals eight.
Read the diagram
Latency budget: 1 + 2 + 1 + 4 = 8 seconds; Epoch 9 published sequence 501; Epoch 10 validates and owns continuation; Destination rejects late epoch 9 playlist publication
Can automatic cross-region failover ignore that the surviving region is already near capacity?
Show answer and explanation
Answer: No. Bound spillover, admission and retries under measured headroom; prioritize the declared experience and degrade deliberately. Failover also needs timeline continuity and ownership checks, not just routing to another hostname.
Live Video Streaming: Check the design
Observe live-edge lag, startup at kickoff, rebuffering, publisher conflict rejection and spare capacity. Test DVR authorization and a missing segment during a timeline handoff.