Design Video Streaming

Someone uploads a 10-minute video from their phone on a shaky train connection. A few minutes later it plays on a TV in full HD, on a laptop in a café, and on a phone in a lift that drops to a lower quality for a few seconds instead of freezing. That is a video streaming service.

Interviewers ask it because the bytes dominate everything. One popular video moves more data in an hour than the metadata database handles in a year, so the design must split the two cleanly: a small, careful system for titles and status, and a huge, dumb, cached system for bytes. The steps follow A Framework for Any Design.

#Clarify the problem

• Functional: upload a video (resumable); process it into formats every device can play; play it with quality that adapts to the network; show title, status and view count.
• Non-functional: playback starts in about 2 seconds and stalls rarely; playback is highly available; videos are ready within minutes of upload; uploaded files are never lost; metadata may be eventually consistent (a view count can lag).
• Out of scope: live streaming, search, recommendations, comments, copy protection.

#Estimate the scale

Start with what viewers do, because that is where the bytes are.

• Concurrent viewers: 50 million × 30 minutes ÷ 1,440 minutes a day ≈ 1 million watching at any moment on average. Assume an evening peak of 2x: 2 million.
• Uploads: 100,000 ÷ 86,400 s ≈ 1.2 a second. Assume an original file averages 1 GB: 100 TB a day of uploads, about 1.2 GB/s coming in.
• Processed copies: five qualities from 240p to 1080p at 0.4 + 0.8 + 1.5 + 3 + 6 = 11.7 Mbit/s together. For 10 minutes: 11.7 × 10⁶ × 600 ÷ 8 ≈ 0.88 GB per video, about 88 TB a day.
• Storage per year: (100 + 88) TB × 365 ≈ 69 PB before replication. Originals are rarely read again, so they can move to cheaper, slower storage.
• Metadata: 100,000 × 365 = 36.5 million new video rows a year at about 1 KB each: 36.5 GB. Tiny next to the bytes.

#Define the API

POST /v1/uploads   { "filename", "size_bytes", "sha256" }
  201 { "upload_id", "chunk_size": 8000000, "chunk_urls": [signed URLs...] }
PUT  <signed chunk URL n>      (8 MB of bytes, goes straight to object storage)
  200 { "etag" }    400 checksum mismatch
GET  /v1/uploads/{id}        -> { "received": [0..111] }   resume from here
                                (the API asks storage which parts landed)
POST /v1/uploads/{id}/complete      safe to repeat: same video_id
  202 Accepted { "video_id", "status": "processing" }
  409 Conflict   chunks missing
 
GET  /v1/videos/{id}  -> { title, status, duration_s, "manifest_url" }
GET  cdn/v/{id}/master.m3u8             manifest: the qualities on offer
GET  cdn/v/{id}/720p/seg_00042.ts       one 4-second segment

The decision worth arguing is where the bytes go. Proxying 1.2 GB/s of uploads through API servers ties them up for minutes per request. Instead the API hands out signed URLs: short-lived links that let the client write one chunk directly to object storage. API servers only handle small JSON. The cost is that the API must check the result at complete, because it never saw the bytes: storage confirms every part arrived with a matching checksum, and the split job, which reads the whole file anyway, verifies the whole-file sha256. complete returns 202, not 201, because the video is not playable yet.

#Model the data

videos:   video_id BIGINT PRIMARY KEY, owner_id BIGINT, title TEXT,
          status TEXT,          -- uploading | processing | ready | failed
          duration_s INT, renditions TEXT, jobs_left INT, created_at TIMESTAMP
uploads:  upload_id, video_id, size_bytes, storage_upload_id, expires_at
          -- which parts arrived is asked of object storage, not stored here
jobs:     job_id, video_id, segment_no INT, rendition TEXT,
          status TEXT, attempts INT, lease_until TIMESTAMP
 
-- object storage keys
originals/{video_id}
v/{video_id}/master.m3u8, v/{video_id}/{rendition}/index.m3u8
v/{video_id}/{rendition}/seg_{n}.ts

The metadata is small (36.5 GB a year), relational and read far more than written, so a relational database with read replicas fits. It gives an atomic counter: each finished job decrements jobs_left, and the job that takes it to 0 writes the manifests and then sets ready. View counts are the exception: batch them through a queue, as in the URL shortener's click counting, so a viral video does not turn one row into a hot spot.

#High-level design

#Deep dives

Interviewers push on four places: uploads that survive bad networks, the transcoding pipeline, how playback adapts, and the cost of delivery.

#Chunked, resumable upload

A single 1 GB PUT that fails at 90% throws away 900 MB, and on a phone it will fail. Split the file into fixed 8 MB chunks: 1 GB is 125 of them. Each chunk is uploaded and checksummed on its own, so a failure costs at most the chunks in flight. Object storage services offer this as a multipart upload: parts arrive in any order, and a final call joins them into one object.

Pick the chunk size from the network. Too small (say 256 KB) and 4,000 requests each pay a round trip. Too large (say 100 MB) and a retry on a slow phone link takes minutes. 4 to 16 MB is a sound middle; I would pick 8 MB. Expire unfinished sessions after a day or two so abandoned parts do not pile up as storage nobody pays attention to.

#Transcoding as a queue of jobs

Phones record in formats and bitrates that many devices cannot play and many networks cannot carry, so each upload becomes five qualities. Encoding a 10-minute video into all five takes about 100 CPU-minutes. Done on one machine, the uploader waits over an hour and a half.

The arithmetic: a 4-second segment takes 4 ÷ 60 × 10 CPU-minutes = 40 CPU-seconds for the whole ladder. With 150 workers free, the 10-minute video is processed in about 40 seconds of wall time instead of 100 minutes, plus queueing. That is a simplification: splitting, uploads to storage and the final step add time, but minutes, not hours.

Make the jobs safe to repeat. Workers lease jobs and write outputs to fixed names, so a job that runs twice, after a lease expires on a slow worker, replaces the same file with an equivalent segment. The finish step must be safe to repeat too: a job decrements jobs_left only when its own row moves from running to done, so a second run cannot count twice. That is idempotency through deterministic output, and it is why the queue only needs at-least-once delivery. "Exactly once" here means exactly one effect, not exactly one run. The queue should also take priorities: a creator with millions of followers waiting should not queue behind a backlog of test uploads.

#Adaptive bitrate streaming

Each quality is cut into the same 4-second segments, listed in a manifest: a small text file naming the qualities and the URL of every segment. (HLS and DASH are the two common manifest formats.) The player downloads segments one at a time and, before each one, picks the quality its measured bandwidth and buffer can sustain. Every segment boundary is a chance to switch, so a slow network means lower quality, not a frozen picture.

The point to make out loud: adaptation lives in the client, so the server side is plain static files. That is what lets a CDN cache them.

#CDN delivery and cost

500 GB/s on average cannot come from one place, and the bill scales with bytes delivered. A CDN keeps segments on edge servers near viewers. If edges answer 95% of requests, origin storage serves 5% of 500 GB/s = 25 GB/s; at 99%, 5 GB/s. Each point of hit rate is a large saving.

Views are lopsided. Popular videos sit in every edge's cache. The long tail of rarely watched videos misses almost every time, so it is cheaper to serve from fewer, larger regional caches than to push it everywhere. A strong answer adds: pre-warm edges for a video you expect to be popular, and make segment URLs identical for every viewer so one cached copy serves them all.

#Bottlenecks and failures

At 10x viewing (10 million concurrent, 5 TB/s), delivery is the whole problem: more CDN capacity, a higher hit rate and a regional cache tier to protect origin. At 10x uploads, transcoding needs about 70,000 busy cores, so make the fleet elastic and let the queue absorb bursts. The metadata database is the last thing to feel it: at 20 page loads per viewer a day, 50 million viewers make 10⁹ ÷ 86,400 ≈ 11,600 reads a second today and about 116,000 at 10x, which read replicas plus a cache cover.

#What a strong answer sounds like

#Follow-up questions

#How would live streaming change this?

Segments are produced in real time, so transcoding must keep up second by second and the manifest is updated as segments appear. Latency becomes a requirement: shorter segments cut delay but add requests and reduce compression efficiency.

#How do you count views?

The player sends a view event after a few seconds of playback, through a queue to a counter that batches updates. Counts lag by seconds and are approximate, which is fine for display.

#How do you stop people downloading paid videos?

Signed segment URLs that expire stop link sharing. The edge checks the signature and leaves it out of the cache key, so one cached copy still serves everyone. Real protection needs encrypted segments and licence keys delivered separately (digital rights management), which is a component you buy, not build.

#Can you save storage on old videos?

Yes: move originals to archive storage after processing, and drop rarely watched qualities for videos nobody watches, regenerating them on demand if a view arrives.

#What if a creator deletes a video?

Mark it deleted in metadata so the API stops returning it, then purge it from the CDN and delete the objects in the background. Edges may serve cached segments until the purge completes, so signed URLs with short expiry help.