Home / Blog / System Design Video Streaming: Interview Talk Track

System Design Video Streaming: Interview Talk Track

Published 2026-10-14 · Luna Interview

"Design a video streaming platform" sounds enormous, and that's exactly why it's a popular prompt. It tests whether you can separate the write path (upload and processing) from the read path (playback at massive scale), and whether you understand why CDNs and adaptive bitrate exist. This system design video streaming interview talk track gives you a structure and ready-to-use sentences for a 45-minute round.

Every company and level runs this differently. Ask whether the interviewer wants breadth across the whole system or depth on one part, such as transcoding or delivery.

1. Clarify requirements (5 minutes)

Scope it out loud:

"I'll design on-demand video: creators upload, we process the video into streamable formats, and viewers watch with smooth playback on different devices and networks. I'll leave live streaming, recommendations, and comments out unless you want them."

Functional requirements

• Users upload videos
• Videos are processed into multiple resolutions and formats
• Viewers stream videos with seek support
• Basic metadata: title, description, view count

Non-functional requirements

• Playback starts fast and rarely buffers
• Very read-heavy: views vastly outnumber uploads
• Highly available reads; uploads can tolerate processing delay (minutes)
• Global audience
• Durable storage—uploaded videos must never be lost

2. Back-of-envelope estimates (3 minutes)

"Assume 500 hours of video uploaded per minute and hundreds of millions of daily viewers. Storage grows fast because each video is stored in several renditions, and egress bandwidth dominates cost. That tells me delivery through a CDN is the most important design choice."

Rough rule worth stating: storing five or six renditions can multiply storage several times over compared with the original.

3. High-level architecture (8 minutes)

Flow sentence:

"The client uploads directly to object storage using a pre-signed URL, which keeps large files off our API servers. An event lands in a queue, transcoding workers produce multiple renditions as short segments plus a manifest, and once processing completes, metadata is marked ready. Viewers fetch the manifest from the playback API and stream segments from the CDN."

4. Deep dive: upload and transcoding

• Resumable, chunked uploads so a dropped connection doesn't restart a 4 GB file.
• Split into chunks for parallel encoding. A long video is cut into segments at keyframes, encoded in parallel across workers, then stitched. This turns hours of processing into minutes.
• Rendition ladder: for example 240p, 360p, 480p, 720p, 1080p, and higher where justified, each at a target bitrate.
• Packaging: output short segments (a few seconds each) with manifests for HLS or DASH.
• Idempotent jobs: each task has an ID; retries don't create duplicate outputs.

"I'd model transcoding as a DAG of tasks—validate, split, encode per rendition, package, generate thumbnails—coordinated by a workflow engine, so failed steps retry independently."

5. Deep dive: adaptive bitrate playback

This is often the "do you really understand streaming" moment.

"The player downloads a manifest listing renditions. It starts with a modest quality, measures throughput and buffer health, and switches renditions segment by segment. Because segments are aligned across renditions, switching is seamless. That's how we get fast start and minimal buffering on unstable networks."

Mention seek: the player jumps to the segment containing the target timestamp, so seeking doesn't require downloading the full file.

6. Deep dive: CDN delivery

• Segments are immutable, so they cache extremely well with long TTLs.
• Popular videos stay hot at edge locations; long-tail videos may fall back to regional caches or origin.
• Origin shielding: a mid-tier cache protects object storage from a flood of edge misses.
• Pre-warming: push segments of an anticipated hit to edges ahead of release.
• Signed URLs or tokens restrict access when content is private or licensed.

"Since egress is the biggest cost, cache hit ratio is my main delivery metric."

7. Metadata and view counts

• Metadata in a relational or wide-column database, keyed by video ID, with a cache in front.
• View counts are write-heavy: aggregate events in a stream and update counters in batches rather than one database write per view. Counts can be eventually consistent.

8. Tradeoffs to say out loud

9. Scaling and reliability

• Autoscale transcoding workers from queue depth
• Replicate raw uploads across regions for durability
• Degrade gracefully: if a high rendition isn't ready, serve lower ones
• Monitor rebuffer rate, startup time, and failed segment requests

10. Wrap-up (2 minutes)

"In short: direct uploads to object storage, an asynchronous parallel transcoding pipeline producing segmented renditions, and delivery through a multi-tier CDN with adaptive bitrate on the client. With more time I'd discuss live streaming, DRM, and per-title encoding optimization."

Soft practice note

A strong system design answer is mostly a calm, well-ordered story. If you want a structured way to rehearse this talk track out loud and keep your pacing steady, Luna Interview is built for practice and prep—before the interview, not as a shortcut during one.

Checklist

• [ ] Scope stated: on-demand, not live
• [ ] Read-heavy asymmetry called out with numbers
• [ ] Pre-signed direct upload explained
• [ ] Chunked parallel transcoding described
• [ ] Adaptive bitrate explained in two sentences
• [ ] CDN caching and origin shielding mentioned
• [ ] Two-sentence summary ready

Rehearse with an AI interview copilot, then browse commonly reported interview questions.