03. Video Streaming / OTT — Interview Q&A

~15 min read · Part 4 of 4 (Overview → HLD → LLD → Q&A)

Q1. 10 million people press play on a new episode at 8pm. How does the system not fall over? Delivery is CDN-first: segments are immutable and identical for everyone, so they cache at the edge. For an anticipated release you pre-warm the edges — push the new episode's early segments to every edge before 8pm. Then 10M players hit warm caches and origin serves almost nothing. The peak egress (tens of Tbps) is spread across thousands of edge locations, not one origin. Common wrong answer to avoid: "Scale up the origin servers." No origin serves 100 Tbps; the whole point is that origin only serves cache-fills.

Q2. Why is transcoding done in chunks, and why does that matter? Split the master into short GOP-aligned segments and encode each into each rendition in parallel across a worker fleet. A 60-minute title becomes thousands of independent encode units, so wall-clock time is the slowest single chunk (minutes), not the whole runtime encoded serially (hours). It also makes retries cheap — a failed chunk re-encodes alone. Common wrong answer to avoid: "Encode the whole file in one pass." That's slow, non-parallel, and a failure wastes the entire encode.

Q3. Who decides the video quality — server or client? The client, per segment. The server ships a manifest (a menu of renditions and segment URLs); the player measures throughput and buffer level and picks each next segment's rendition. This keeps servers stateless and puts adaptation where the bandwidth signal actually is — at the player. Common wrong answer to avoid: "The server picks quality based on the user's plan." Quality must adapt to live network conditions, which only the client observes; a fixed server-side choice causes buffering when bandwidth drops.

Q4. A viewer's wifi drops from 8 Mbps to 1 Mbps mid-episode. What happens? Adaptive bitrate: the next segment is fetched at a lower rendition (say 480p instead of 1080p). Quality dips for a few seconds but playback doesn't stall, because the player's buffer covers the transition and it selects a rendition it can actually download in time. When bandwidth recovers, it steps back up. Common wrong answer to avoid: "It buffers until bandwidth returns." Rebuffering is the failure ABR exists to prevent; you drop quality, not playback.

Q5. Where does the video actually live, and how do you manage petabytes of it? Immutable segments and manifests live in blob storage, tiered: hot titles on fast/edge storage, the long-tail catalog on cheaper cold storage, masters archived even colder (needed only to re-transcode). The CDN caches hot content at the edge. This matches the access pattern — a few titles watched constantly, most watched rarely. Common wrong answer to avoid: "Keep everything on fast storage." Petabytes of rarely-watched long-tail on premium storage is wasteful; tier by access frequency.

Q6. Why do immutable segments matter for delivery? Because they cache perfectly. Every viewer of a title requests the exact same segment URLs, so an edge caches each segment once and serves it to everyone. Immutability is what makes the CDN able to absorb the entire delivery load with a near-100% hit ratio. Common wrong answer to avoid: "Generate a personalized stream per viewer." Per-viewer streams can't be cached, forcing origin to serve everyone — the opposite of scalable.

Q7. How do you keep startup latency under two seconds? Start conservative: the player picks a low-ish rendition for the first segment so it downloads fast, begins playback, then ramps up. Combined with pre-warmed edges (segment 0 is a cache hit) and a manifest fetch that's a small request, the time-to-first-frame stays low. Common wrong answer to avoid: "Start at the highest quality the plan allows." An optimistic first segment on an unknown network delays the first frame and risks an immediate stall.

Q8. A transcode worker crashes halfway through a title. What's the blast radius? One chunk-rendition unit. Jobs are keyed by (title, segment, rendition) and idempotent, so a retry re-encodes only the failed unit; completed segments are untouched. The manifest is published only when all units are done, so the player never sees a missing segment. Common wrong answer to avoid: "Re-transcode the whole title." That wastes hours of completed work for one failed chunk.

Q9. How does DRM coexist with edge caching? Segments are stored encrypted, so the encrypted bytes still cache at the edge like any other segment. The player fetches a license (a per-title key) from a separate license service and decrypts locally. Caching operates on ciphertext; only the small license request is per-user. Common wrong answer to avoid: "Encrypt per viewer at the edge." Per-viewer encryption breaks caching; encrypt once per title and distribute keys separately.

Deeper follow-ups

• How would you decide which titles and renditions to pre-warm to which edges?
• How would you support offline downloads on mobile devices?
• How would you add per-title/per-scene bitrate optimization (encode complexity varies)?
• How would you measure and alert on perceived quality (rebuffer, startup) per region?
• How would you handle a viral long-tail title that suddenly spikes from cold storage?
• What changes for live streaming, where you can't pre-encode or pre-warm?

How this round is scored

The OTT round is won by recognizing the one number that dominates — the egress bandwidth — and immediately reframing delivery as a distribution problem for the CDN, not a compute problem for origin. The senior signal is the pre-warm-the-edge insight for big releases (the thundering herd is about cold caches, not total bytes), plus putting ABR at the client with the manifest-as-menu framing so servers stay stateless. Chunk-level parallel transcoding with idempotent retries shows you understand the offline pipeline. Weaker answers try to scale origin or let the server pick quality; strong answers keep origin quiet and let immutable segments plus client-driven adaptation do the work.