Design a video platform

Creators upload hours of video; viewers on phones, laptops and TVs press play and expect it to start in a second and never stall, on fibre or on a train. A video platform is three systems joined together: an upload path that must survive flaky connections, a processing pipeline that turns one file into dozens, and a delivery network that streams enormous amounts of data from servers close to every viewer. It follows the interview framework phase by phase.

1. The prompt

"Design YouTube: upload videos, watch them on any device, with titles, thumbnails, view counts and a home page of recommendations."

Metadata and accounts are ordinary. The interview is about three heavy paths: getting multi-gigabyte files in over bad connections, turning each into a ladder of formats quickly, and delivering more than 100 terabits a second without stalls.

2. Frame the problem

3. What it must do

1. A creator can upload a video (up to several GB) with a title, description and thumbnail.
2. A viewer can watch a video on any device, at the best quality their connection allows.
3. Viewers see view counts and a home feed of recommended videos.

Not now:

• Live streaming.
• Comments: a separate service.
• Monetisation.
• The recommendation model: we design around its serving layer.

4. How well it must do it

5. Numbers that change the design

6. The nouns

• Video: with its status.
• Upload: a multipart upload session.
• Rendition: one resolution and bitrate.
• Segment: a few seconds of one rendition.
• Manifest: the playlists.
• View event.

videos      video_id, owner_id, title, description, status (uploading | processing | ready | blocked), duration, thumbnail_key
renditions  (video_id, resolution, codec) → bitrate, manifest_key, status
storage     raw/{video_id}  ·  v/{video_id}/{rendition}/{n}.m4s  ·  v/{video_id}/master.m3u8
view events video_id, viewer, seconds_watched, time   (stream → counts)

7. The contract

POST /v1/videos {title, size} → 201 {video_id, upload: {upload_id, part_urls[...]}}   (presigned multipart, Module 10)
POST /v1/videos/{id}/complete {parts: [...]}           → 202 (processing starts)
GET  /v1/videos/{id}  → {title, status, manifest_url: "https://cdn…/v/{id}/master.m3u8", thumbnail}
GET  /v1/feed         → recommended videos
POST /v1/videos/{id}/views {seconds_watched}          (batched by the player)

Data flow: (1) the creator uploads parts straight to storage → (2) "upload complete" starts a workflow → (3) split, encode in parallel, build manifests → (4) mark ready → (5) players fetch playlists and segments from the CDN → (6) view events flow to counting.

8. First working version

An API, object storage, a queue of transcoding jobs, workers, a metadata database and a CDN.

8.1 Uploading

Version one streams the file through the API server into storage, then enqueues a transcoding job.

8.2 Transcoding

One worker takes the job and encodes the whole file into each resolution, one after another, then marks the video ready.

8.3 Watching

The player downloads one MP4 file at a fixed quality through the CDN, and each view increments a counter in the database.

9. Make it hold up

9.1 Uploading big files over bad connections reliable uploads

9.2 Transcoding: one file into many starts fast · scale

• Why: the uploaded file is in whatever format the camera made. Every device needs common codecs (H.264 for compatibility; more efficient codecs such as VP9, HEVC or AV1 where supported) at several resolutions and bitrates: a bitrate ladder (say 240p to 4K).
• Chunked and parallel: split the video into segments of a few seconds, encode each segment for each rendition on separate workers, then assemble. A one-hour video finishes in minutes instead of hours, and a crashed worker redoes one segment.
• As a workflow: validate → split → encode (fan-out) → assemble manifests → thumbnails → moderation and copyright checks → mark ready. A workflow engine (Module 22) tracks it, retries steps and resumes after crashes.
• Prioritise: make a low resolution available first so the video is watchable quickly, then fill in higher ones.

9.3 Adaptive streaming starts fast · rarely stalls

Each rendition is cut into segments of a few seconds and listed in a playlist (HLS .m3u8 or DASH .mpd); a master playlist lists the renditions. The player downloads segments over plain HTTPS, measures throughput and how much video it has buffered, and picks the quality for the next segment. When bandwidth drops, it steps down before the buffer empties; when it recovers, it steps back up. Because segments are ordinary files, CDNs cache them like images. Try it in section 13.

9.4 Delivering 100+ Tbit/s scale · starts fast

Popular videos are cached at CDN edges, and the biggest platforms place cache servers inside ISPs' networks (Netflix's Open Connect works this way) so traffic barely crosses the internet. Popularity is extremely skewed: a small share of videos makes most views, so edges hold the head while the long tail is fetched from regional caches or origin storage on demand. Segment URLs are signed and expiring for private or paid videos (Module 10).

9.5 Metadata, views and recommendations scale

• Metadata (titles, owners, status) is small and read-heavy: a sharded database plus a cache, with search through a search engine.
• View counts are high-volume and need not be exact in real time: players send batched events to a log; a stream job aggregates counts (Design D17) and periodically updates the displayed count, with fraud filtering for fake views.
• Recommendations are a separate system: candidate generation and ranking models trained on watch history offline, with a serving layer that returns a ranked list in milliseconds.

9.6 Storage cost and moderation durable · scale

• Tiering: keep originals and popular renditions in standard storage; move rarely watched videos to cheaper, slower tiers, and re-encode expensive codecs only for videos that become popular.
• Durability: originals are kept (replicated or erasure-coded across zones) so any rendition can be regenerated.
• Moderation and copyright: classifier and fingerprint checks run as workflow steps; videos can be held, limited or blocked, and blocks purge CDN caches.

9.7 The whole design after the deep dives

From upload to playback through the final design.

10. Interviewer follow-ups

Variation: a subscription service with a fixed catalogue

A common twist: "Now design it for a paid streaming service like Netflix: no uploads, a catalogue of films and series." The pipeline above still works, but three of its assumptions flip, and the design moves with them.

• Few titles, watched a lot. Tens of thousands of titles instead of billions of videos, each watched millions of times. Encoding can be slow and thorough: a bitrate ladder tuned per title (even per scene) and several codecs, because every byte saved is saved millions of times.
• Demand you can predict. Tonight's popular titles are known this afternoon: new episodes, what's trending in each country. So the caches are filled ahead of time, during the quiet hours, instead of filling on a miss at peak time. The caches sit inside internet providers' networks, so most bytes never cross the wider internet.
• Pressing play is the hard path. One call has to check the subscription and the licence for this country, pick caches that hold the files and are close and healthy, and hand back a manifest and a decryption licence, all in a few hundred milliseconds.
• Licences by country and date. Each title has availability windows per country, so the catalogue, search and home rows are filtered per country, and a title can disappear at midnight on a fixed date.
• The home screen is personal. The rows ("because you watched…") are computed offline per user and served from a cache; only the ordering is adjusted live.

Read more: Open Connect, Netflix's own delivery network, describes appliances placed inside providers' networks and filled nightly.

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Multipart uploads straight to storage.
• Chunked parallel transcoding as a workflow (more moving parts, much faster).
• Adaptive streaming over HTTP (cacheable, a few seconds of buffer).
• ISP-embedded caches for egress.
• Asynchronous view counting.
• Storage tiering and on-demand renditions (cheaper, a slower first view for old videos).

What we'd watch:

• Time to first frame.
• Rebuffering ratio.
• Upload success rate.
• Processing time to "ready".
• CDN hit rate.
• Egress cost per hour watched.

At 10×:

• More ISP caches.
• Per-title encoding.
• Aggressive tiering.

Common mistakes:

• Uploading through API servers.
• Encoding a whole file on one machine.
• A single fixed quality.
• Ignoring egress.
• Counting views with database writes.
• Forgetting moderation.

13. Try it, check yourself, read more

A 60-second playback. The player chooses a quality for each 2-second segment from the measured bandwidth and its buffer. Pick a network and a strategy.

Ladder: 240p 0.4, 480p 1.5, 720p 3, 1080p 6 and 4K 16 Mbit/s. Top: coloured bars are the quality chosen for each segment, the dashed line is the network's real bandwidth (same scale). Bottom: the buffer; red marks stalls.