SWE System Design Video Streaming Platform

Introduction

“Design a video streaming platform” is one of the most frequently asked system design questions at every level from mid-level to staff engineer, because it touches nearly every hard problem in distributed systems: massive storage, global content delivery, transcoding pipelines, metadata consistency, and read-heavy traffic patterns that dwarf almost any other consumer product. This article walks through a complete design for a YouTube-like platform, the key components an interviewer expects you to identify, and the tradeoffs that separate a mid-level answer from a staff-level one.

The core challenge is not “how do I store a video file” — that’s trivial with object storage. The real difficulty is the pipeline between upload and playback: transcoding into multiple resolutions and formats, replicating that content globally so playback is fast everywhere, and serving metadata (views, likes, recommendations) at a scale where a single database simply cannot keep up.

Core Architecture Components

A video streaming platform breaks cleanly into five subsystems, and structuring your interview answer around these five buys you clarity and time.

1. Upload and ingestion service. Handles resumable, chunked uploads (so a dropped connection doesn’t restart a 2GB upload from zero) and writes the raw file to a staging object store (S3-compatible). It emits an event to trigger the transcoding pipeline.

2. Transcoding pipeline. A fleet of workers (often on spot/preemptible compute, since transcoding is CPU-bound and interruptible) picks up raw uploads and produces multiple resolution/bitrate variants (240p through 4K) in formats like HLS or DASH, segmented into small chunks for adaptive bitrate streaming.

3. Storage and CDN. Transcoded segments are pushed to origin storage, then cached at edge CDN nodes close to viewers. The CDN is what makes global playback fast — without it, every viewer request round-trips to a single origin region.

4. Metadata service. Stores video metadata (title, description, owner, status), and separately, high-write-volume counters (views, likes) that need eventual consistency, not strong consistency, to avoid becoming a bottleneck.

5. Playback and recommendation service. Serves the client a manifest file listing available quality levels, and separately, a personalized set of recommended videos, usually computed offline and served from a fast key-value cache.

Upload -> Ingestion Service -> Raw Storage -> Transcoding Queue -> Transcoding Workers
                                                                          |
                                                                          v
                                                              Transcoded Storage (per-resolution)
                                                                          |
                                                                          v
                                                                    CDN (edge cache)
                                                                          |
                                                                          v
                                                                    Client Player

Handling Scale: The Hard Parts

The naive version of this design works for a demo but falls over at scale in three specific places, and interviewers listen for whether you catch them proactively.

View counters at billions of writes/day. Writing directly to a relational counter column for every view would create unbearable write contention. The standard fix is to batch view increments in-memory (or in a stream processor like Flink) and flush aggregated counts to the database every few seconds, trading a small amount of counter accuracy for enormous write throughput reduction.

Transcoding cost and latency. Transcoding a 4K video into 6 output variants is expensive and can take minutes. Popular platforms prioritize: transcode a fast, low-quality version first so upload-to-playback latency is low, then backfill higher qualities asynchronously. This “progressive availability” detail is a strong signal in an interview.

Storage cost at petabyte scale. Most videos are watched heavily in the first few days and then rarely again. A tiered storage strategy — hot storage for recent/popular content, cold storage (Glacier-tier) for old, rarely-watched content, rehydrated on demand — meaningfully cuts cost without hurting the common case.

Comparison Table: Design Choices and Tradeoffs

Interviewing on This Question

The strongest answers open with clarifying questions: expected scale (uploads/day, concurrent viewers), whether live streaming is in scope, and whether global distribution is required. Then they move through ingestion, transcoding, storage/CDN, and metadata in that order, explicitly calling out the view-counter and progressive-transcoding tradeoffs before the interviewer has to prompt for them. Staff-level candidates additionally discuss failure modes: what happens if a transcoding worker crashes mid-job (idempotent, resumable jobs keyed by video ID and segment), and how you’d roll out a new codec without breaking older client players (versioned manifests, backward-compatible formats).

If you want a repeatable framework for structuring answers like this across dozens of system design prompts — not just video streaming, but messaging queues, rate limiters, and distributed caches — The 0-to-1 SWE Interview Playbook (https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) is built around exactly this kind of component-by-component breakdown with the tradeoffs interviewers actually probe for.

FAQ

Q: Should I mention specific technologies like AWS MediaConvert or FFmpeg in the interview? A: Yes, briefly. Naming a real tool (FFmpeg for transcoding, HLS.js for playback, CloudFront or Akamai for CDN) shows you’ve built something real, but don’t let tool names replace explaining the underlying tradeoff — the interviewer cares more about why than which vendor.

Q: How do I handle live streaming differently from video-on-demand in this design? A: Live streaming removes the transcoding-then-store step and instead transcodes in near-real-time with a small rolling buffer (a few seconds of latency), pushing segments to the CDN as they’re produced rather than after the full video is processed. It also needs a different scaling story for concurrent viewership spikes tied to a single live event.

Q: What’s the single most common mistake candidates make on this question? A: Spending too much time designing the database schema for video metadata and too little time on the transcoding pipeline and CDN strategy, which is where the actual scale challenges live. Budget your interview time proportionally to where the hard problems are.