Case Study 5: YouTube / Hotstar Video Streaming

Video upload, transcoding and smooth adaptive streaming to tens of millions of people through a CDN, both VOD and live events like the IPL.

C.1 Requirements

Functional requirements:

• A creator can upload videos (large files, resumable upload).
• Videos are transcoded into multiple resolutions (240p to 4K) and codecs.
• The viewer watches video with HLS/DASH adaptive bitrate: quality changes with the network.
• Live streaming: an event like an IPL match is watched by crores of people at once, with low delay.
• Search, video metadata (title, description, thumbnail) and view count.
• Watch history and resume playback (from where you left off).
• DRM and an entitlement check (subscription) for paid content.

Non-functional requirements:

• Playback availability 99.99%; video start time < 2 seconds, rebuffering ratio < 1%.
• Live glass-to-glass latency 10-30 seconds (standard HLS), ~3-5 seconds in low-latency mode.
• Live peak: 2-3 crore+ concurrent viewers (Hotstar has publicly reported 2.5 crore+ concurrency during the IPL).
• Durable uploads: not a single uploaded video may be lost (S3-like 11 nines).
• Egress bandwidth at the Tbps level: 90%+ of traffic must be served by the CDN, not the origin.
• Eventual consistency is OK for view counts and metadata.

C.2 Estimation (back-of-the-envelope)

C.3 API design

C.4 Data model

C.5 High-level architecture

• Playback: the app picks the CDN + region via DNS/GSLB, LB -> API Gateway -> Playback Service; it checks entitlement in Redis and returns a signed manifest + DRM URL.
• The player fetches segments straight from the Multi-CDN edge; on a miss, origin shield -> S3 Origin. 90%+ of traffic comes from the CDN, not the origin.
• Upload: Creator -> Upload Service puts chunks in S3; on complete a Kafka job -> Transcoding Workers -> Packager -> S3.
• Live: stadium feed -> Live Ingest (2 regions) -> Live Transcoder -> Packager -> S3 origin; Kafka events go to Thumbnail, Search, Analytics.
• Bandwidth math: IPL 2.5 cr x 2.5-3 Mbps = 60-75 Tbps; hence multi-CDN and a 95%+ cache hit are essential.

C.6 Main flows

Video upload and transcoding:

1. The creator app gets an upload_id from POST /v1/uploads.
2. The file goes in 10 MB chunks via S3 multipart upload; if the network breaks only missing chunks are retried.
3. On the complete call the Upload Service sets video status = processing and puts a transcode job on Kafka.
4. The splitter cuts the video into small chunks (at GOP boundaries) so it can be transcoded in parallel.
5. Transcoding Workers encode every chunk in every resolution/bitrate, with output going to S3.
6. The Packager joins the segments into HLS/DASH manifests and applies DRM encryption.
7. Thumbnail and content moderation workers run in parallel.
8. When everything is ready, status = ready, the Search Indexer is updated and subscribers are notified.

VOD playback (adaptive bitrate):

1. The user presses play and the app calls GET /v1/videos/{id}/playback.
2. Playback Service checks entitlement in Redis and returns a signed master manifest URL.
3. The player fetches the master manifest from the CDN; it lists all quality levels.
4. The player estimates bandwidth, picks a rendition and fetches segments from the CDN edge.
5. On an edge cache miss it fetches from the mid-tier/origin shield, then from the S3 origin.
6. If the network slows, the player picks the next segment at a lower bitrate (ABR); no rebuffering.
7. The player sends progress and a QoE heartbeat every 30 sec.

Live IPL streaming:

1. The stadium production feed arrives over SRT/RTMP at redundant ingest servers (two regions).
2. The live transcoder produces multiple bitrates in real time, in 4-6 sec segments.
3. The Live Packager writes the new segment to the origin and updates the media playlist.
4. Multiple CDNs sit behind an origin shield; the CDN TTL of every playlist is very short (1-2 sec), segments get a long one.
5. Crores of players refresh the playlist every few seconds and fetch new segments from the edge.
6. Request coalescing: when thousands of identical requests miss at one edge, only one request goes to the origin.
7. Under overload, graceful degradation: lower the default bitrate, switch off non-critical features (comments, recommendations).

C.7 Deep dives

Problem: crores of concurrent viewers at live peak and origin overload. Multi-CDN + origin shield + request coalescing; 95%+ cache hit. Pre-warm capacity and load test before the match, because autoscaling takes minutes while traffic rises in seconds at the toss.

Problem: thundering herd: everyone logs in/refreshes at once at match start or a wicket. Cache and pre-compute login, entitlement and config; client-side jitter and exponential backoff; API Gateway rate limiting; switch off non-critical APIs with a feature flag (graceful degradation).

Problem: transcoding a large video is slow (a 1-hour 4K video). Split the video into chunks and transcode in parallel on thousands of workers (map-reduce style). Use a priority queue for popular creators; publish the low resolution first, HD later.

Problem: buffering on a poor network (2G/3G, crowded towers). ABR (HLS/DASH) switches quality on every segment; use small segments; efficient codecs (H.265/AV1) give the same quality at a lower bitrate; the player adapts to its buffer health.

Problem: storage cost growing to exabytes. Keep popular videos on a hot tier and old/rarely watched ones on cold storage (S3 Glacier-like); for the long tail keep only a few renditions and transcode the rest on demand.

Problem: piracy and unauthorised access. DRM (Widevine, FairPlay, PlayReady) segment encryption, signed CDN URLs with a short expiry, a concurrent stream limit per account, forensic watermarking.

C.8 Trade-offs

C.9 Interview tips

• Design the upload path and the playback path separately: their scale and nature differ.
• Explain adaptive bitrate and segments clearly (manifest + chunks).
• Show the bandwidth math: concurrent x bitrate = Tbps; it proves the importance of the CDN by itself.
• For live, always mention the thundering herd, pre-warming and graceful degradation.
• Explain transcoding as a queue + parallel workers + idempotent jobs.