Question 1

How does HLS adaptive bitrate streaming work?

Accepted Answer

HLS (HTTP Live Streaming) splits each video into small segments (2-10 seconds). For each quality level (360p, 720p, 1080p, 4K), a separate set of segments is encoded and stored. A master manifest (m3u8) lists all quality levels with their bandwidths and URLs. The player downloads the master manifest, selects an initial quality based on current bandwidth estimate, downloads that quality's segment manifest (which lists all segment URLs), and fetches segments sequentially to fill the playback buffer. The ABR (Adaptive Bitrate) algorithm monitors download speed and buffer level continuously: if download speed drops below the current quality's bitrate (buffer draining), switch to the next lower quality by fetching the same timestamp segments from the lower-quality manifest. If download speed improves and buffer is healthy, switch to higher quality. This prevents buffering while maximizing quality.

Question 2

How does CDN pre-warming work for popular video content?

Accepted Answer

For known-popular content (new Netflix episode releasing at midnight, Super Bowl stream), CDN pre-warming pushes video segments to all edge nodes before the event starts, ensuring 100% cache hit rate from the first request. Process: origin pushes the segment list to CDN edge nodes; edges prefetch and cache all segments. This eliminates origin requests during the spike — a new Netflix season with 100M viewers would overwhelm any origin without pre-warming. For long-tail content (old videos), pre-warming is not cost-effective — serve on-demand with a cache hierarchy (edge → regional PoP → origin). Regional PoPs serve as a mid-tier cache: cache miss at the edge hits the regional PoP (faster than origin), and the PoP caches the segment for subsequent edge requests from the same region.

Question 3

How do video platforms scale view count updates?

Accepted Answer

Writing one database row per view is catastrophically unscalable — a viral video with 1M views/hour generates 278 writes/second, causing write lock contention and deadlocks. Solution: in-memory counters with batch flush. (1) Use Redis INCR to increment an in-memory counter per video_id — sub-millisecond, handles 100k+ increments/second per key. (2) Every 60 seconds, a batch job reads all Redis counters and flushes them to the database with a single UPDATE videos SET view_count = view_count +  WHERE id = . This reduces database writes from 278/second to 1/minute per video. Redis provides fast real-time reads (ZSCORE); the database has eventually-consistent, durable counts. For analytics (watch time, retention, geographic breakdown), use a separate pipeline: Kafka events → Spark → BigQuery — never aggregate from the primary database.

Question 4

What are the stages of a video encoding pipeline?

Accepted Answer

(1) Ingest: raw video uploaded to object storage (S3). A 1-hour 4K video is 50-100GB. The upload should go directly to S3 (pre-signed URLs), not through the API server. (2) Validation and metadata extraction: verify the file is a valid video, extract duration, resolution, codec, framerate. (3) Transcoding: encode into multiple quality levels using H.264 or H.265. FFmpeg workers or managed services (AWS Elemental MediaConvert) process the video. Encoding is 1-3x the video duration — a 1-hour video takes 1-3 hours on a single machine. Parallelize by splitting into segments and encoding segments concurrently across multiple workers. (4) Packaging: convert encoded video into streaming format (HLS segments with m3u8 manifests or MPEG-DASH). (5) CDN distribution: push manifest and segment files to CDN origin. The entire pipeline completes before the video is made available to viewers.

Video Streaming Platform: Low-Level Design

Video Ingestion and Encoding

HLS and Adaptive Bitrate Streaming

CDN Architecture

Metadata and Recommendations

View Count and Analytics