Designing a Video Streaming Service

requirements

A video platform — call it Reelhouse — lets creators upload video and viewers stream it on demand. This case study is a good capstone for the track because it forces two very different subsystems to work together: a write path (ingesting and processing large files) and a read path (delivering video smoothly to millions of concurrent viewers) with almost nothing in common.

Functional	Non-functional
Upload a video	Playback must start quickly and not stall (buffer) mid-stream
Stream video on demand, adjusting quality to the viewer's connection	Must support a huge range of device types and network conditions
Browse/search available videos	Storage and bandwidth costs at this scale are enormous and must be controlled

why raw uploaded video can't be served directly

A creator's uploaded file might be a large, high-bitrate master file in one specific format. Serving that same file directly to every viewer would waste enormous bandwidth on viewers with small screens or slow connections, and would fail entirely for devices that don't support that file's codec. The fix is transcoding: process the uploaded master into multiple resolutions and bitrates ahead of time, so playback can pick the version that fits each viewer's actual device and connection.

the upload and processing pipeline

Step	What happens
Upload	The raw file is written to blob storage — never a database, given the size.
Enqueue processing	An upload event is placed on a distributed messaging queue, decoupling upload from the (much slower) transcoding step.
Transcode	A task scheduler distributes transcoding jobs — producing several resolution/bitrate variants — across a worker pool, since transcoding is CPU-intensive and fully parallelizable across videos.
Publish	Once transcoding completes, the video's metadata (available resolutions, thumbnail, duration) is written to the catalog database and the video becomes visible for playback.

This pipeline is intentionally asynchronous end to end — a creator doesn't wait for transcoding to finish before their upload "succeeds"; the video simply becomes playable once processing catches up, exactly the same decoupling principle from Synchronous vs. Asynchronous Service Communication.

the distinctive component: adaptive bitrate streaming

Rather than picking one fixed quality for an entire viewing session, modern streaming splits each transcoded variant into a few seconds worth of small segments, and the video player requests one segment at a time — checking its own current download speed before requesting the next one, and switching up or down in quality mid-playback as network conditions change.


Available variants for one video:
  240p @ 400 kbps   360p @ 800 kbps   720p @ 2500 kbps   1080p @ 5000 kbps

Player logic (simplified):
  measured_bandwidth = last_segment_size / download_time
  next_segment_quality = highest variant whose bitrate <= measured_bandwidth

This is what actually prevents playback from stalling on a fluctuating connection — the player degrades quality smoothly instead of freezing to rebuffer at a fixed quality it can no longer sustain.

delivering video at scale: this is what CDNs are for

Video is exactly the workload a CDN is built for: large, static (once transcoded, a segment never changes), and requested repeatedly by many geographically spread-out viewers. Reelhouse's origin storage holds the authoritative transcoded segments; a CDN caches them at edge locations close to viewers, so the origin only serves each segment once per region rather than once per viewer — the same push/pull edge-caching pattern covered in Content Delivery Networks (CDNs), applied to video segments instead of images.

evaluation

Requirement	How it's met
Fast playback start, no stalling	Adaptive bitrate streaming adjusts quality to real-time bandwidth instead of committing to one fixed quality.
Wide device/network support	Transcoding produces multiple resolution/bitrate variants ahead of time, not on demand per viewer.
Controlled bandwidth and storage cost	CDN edge caching means the origin serves each segment once per region; asynchronous transcoding runs once per video regardless of eventual view count.
Upload doesn't block on processing	The upload and transcoding pipeline is fully decoupled via a queue and a task scheduler.

reference

Approaching a System Design Interview (RESHADED)