Loading…

The decisions that matter

Every play served from CDN edges, with storage as the origin for misses.Only servers near viewers can send the busiest hour and start a picture in about two seconds.
Resumable uploads in parts, straight to object storage.A dropped phone connection resends one part, not the file.
Segments in several qualities, with an HLS or DASH manifest.The player changes quality as the connection changes.
Short-lived tokens checked at the edge and kept out of the cache key.Takedowns reach viewers within minutes, and allowed viewers still share one cached copy.

Architecture diagramThe final design at a glance

Uploads go straight to storage and are converted off the request; every play is served from caches near the viewer, and storage sees only the misses a regional shield lets through. Dashed lines are asynchronous.

Diagram as text

Components: Creator app (Client); Upload API (Service); Processing queue (Queue); Transcoding workers (Worker); Object storage: originals, segments (Object store); Playback API (Service); Video records (SQL DB); Player (Client); CDN edges (CDN); Regional shield (CDN); View events (Queue); Counts and data feeds (Worker). Connections: Creator app → Upload API (start, complete); Upload API → Processing queue (job), asynchronous; Processing queue → Transcoding workers (take a job), asynchronous; Creator app → Object storage: originals, segments (parts, straight to storage); Transcoding workers → Object storage: originals, segments (segments, manifests); Upload API → Video records; Playback API → Video records (ready? allowed?); Player → Playback API (play); Player → CDN edges (segments); CDN edges → Regional shield (misses); Regional shield → Object storage: originals, segments (one fetch per region); Player → View events (a play happened), asynchronous; View events → Counts and data feeds (per-minute totals), asynchronous.

Understanding the problem

A video platform takes uploads of any length, prepares each for playback, and lets tens of millions of people watch at once on any device. Far more video goes out than comes in, so where viewers download from shapes everything. This page designs the family’s one variant, Video platform.

Confirm the brief's requirements in the first few minutes. The core is two paths: a creator's upload becoming playable, and a viewer pressing play.

Functional requirements

CoreCreators upload a video file of up to 256 GB, with a title and description, from a phone or a browser.
CoreCreators see whether each upload is still being processed, is ready to watch, or has failed.
CoreAnyone can watch a ready video on a phone, TV or browser, and jump to any point in it.
CoreOwners see how many times each of their videos has been watched.
CoreOwners can delete a video or make it private, and trust and safety can take a video down.
CoreSearch and recommendations, run by other teams, get the data they need about new videos and what people watch.
Below the lineThumbnails and captions.
Below the lineComments, likes and subscriptions.
Below the lineSaved lists of videos and watch history.
Below the lineResuming a video on another device.Watch history is below the line in the brief; a position per viewer and video would add it later.

Non-functional requirements

LatencyPlayback starts within about 2 seconds, rarely stalls, and the picture quality follows each viewer's connection as it changes.
AvailabilityPlayback stays available (99.99%), even while a whole region is down.
QualityA dropped connection never sends a creator back to the start of an upload.
DurabilityOnce an upload is confirmed, the original file is never lost.
LatencyMost videos are ready to watch within minutes of the upload finishing, and a creator can always see where their video is.
ConsistencyA deleted, private or taken-down video stops playing everywhere within about 5 minutes.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 500 hours of video uploaded every minute; files from a few megabytes to 256 GB.
ScaleAbout 1 billion hours watched every day; about 60 million people watching at once at the busiest time.
ScaleA new video from a very popular creator can draw millions of viewers in its first hour.
ScaleViewers and creators all over the world; the platform runs in several regions.

Out of scope

Out of scopeLive streaming: every video is uploaded first, then watched.
Out of scopeHow search and recommendations rank videos.
Out of scopeCopyright matching, DRM and copy protection.
Out of scopeDeciding which plays count as real views (filtering bots).
Out of scopeSign-up, channels, ads and payments to creators.

Check yourself

Which requirement rules out streaming video from your own servers?
Show answerHide answer
Playback that starts in about two seconds for tens of millions of viewers worldwide: a few regions of servers can neither send that much nor reach other continents that fast.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Work out only the numbers this design depends on, and say the bitrates you assume.

Back of the envelope for the video platform

Quantity	Value	Working
Video arriving	About 30,000 seconds a second	500 hours a minute, times 3,600, divided by 60.
Upload traffic	About 300 Gbps	At about 10 Mbps an original.
Storage added	About 6.5 PB a day	The original plus every quality at about 20 Mbps together, 2.5 MB per second of video.
Sent at the busiest time	About 180 Tbps	60 million viewers at about 3 Mbps each.
Converting machines	About 30,000	If one machine converts a video into every quality in about its own length.

What the numbers tell you

Out is about 600 times in: where viewers download from is the design question.
Storage grows by over 2 EB a year: what is kept where is a cost question.

Read:Learn: Numbers and capacity estimation

Try it: The numbers that shape the designGuided practice · Video streaming, Video platform · Senior

Check yourself

Which number decides the play path?
Show answerHide answer
The traffic going out: about 180 Tbps at the busiest time, hundreds of times the uploads, which only servers near viewers can send.

Core entities

Two kinds of data, two stores. Video files are huge, written once and read by millions; records are tiny and looked up by id, and each points at where its files live. Private and unlisted are visibility settings on a ready video, not statuses.

The records that matter

Record	Key fields	Why it exists
Video	`video_id`, owner, title, status, visibility	Read on every play; the status is what the creator watches.
Upload	`upload_id`, `video_id`, size, parts received, expiry	An upload in progress; abandoned ones are cleaned up.
Video file	`video_id` + quality, codec, bitrate, path	One row per quality; the bytes live in object storage.
Creator video	`owner_id` + created, `video_id`	A creator's list, newest first, in one lookup.

How a video’s status moves

From	To	Because
uploading	processing	The upload is complete.
processing	ready	The playable versions exist.
processing	failed	The file cannot be converted.
ready	removed	The owner deletes it, or trust and safety takes it down.

Architecture diagramSmall records in a database, big files in object storage

Read:Learn: Data model design Learn: Storage choice justification Learn: S3 / Blob Storage Learn: PostgreSQL

Try it: Video records and video filesGuided practice · Video streaming, Video platform · Senior

Keep reading+1 min

Which stores

Records: MySQL or PostgreSQL split by video id, with creator lists kept by owner, or a distributed database with global indexes. Files: object storage such as S3, under a path per video, which keeps several copies of every file.

Check yourself

The API

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

The API servers hand out permission and don't carry video: parts go straight to object storage through signed URLs, and the play call returns where to fetch the video.

Size parts from the file. S3, for example, allows at most 10,000 parts of 5 MiB to 5 GiB each (Amazon S3 (opens in a new tab)), so a 4 GB file can use 16 MB parts and a 256 GB file needs parts of about 26 MB or more, say 32 MB. A failed part is sent again on its own, and a lifecycle rule deletes incomplete uploads after a few days (Amazon S3 (opens in a new tab)).

The calls

Call	Request	Response	Errors
`POST /v1/videos`	Title, description, size	`201`: video and upload ids, part size, the first part URLs	`400`, `401`
`PUT <part URL>`	One part's bytes	An ETag, from object storage	Send that part again
`GET /v1/uploads/{id}`	Nothing	Parts received, URLs for the next parts	`404`
`POST /v1/uploads/{id}/complete`	Part numbers and ETags	`202`: status processing	`400`, `409`
`GET /v1/videos/{id}`	Nothing	Title, owner, status, visibility, views	`404`, `410` once removed
`GET /v1/videos/{id}/play`	Nothing	Playback URL and its expiry	`403` private, `409` not ready, `410`
`PATCH`, `DELETE /v1/videos/{id}`	Visibility, or nothing	The video, or `204`	`403` unless the owner

Read:Learn: API contract design Learn: Large file upload & blob handling Learn: S3 / Blob Storage

Try it: Uploading a big file, and starting to watchGuided practice · Video streaming, Video platform · Senior

Keep reading+1 min

A resumable session works too

One upload URL, and the app asks how many bytes arrived before continuing, as in Google Cloud Storage. It is an equally good design; what matters is that a drop resends only what is missing.

Check yourself

The phone loses signal 3 GB into a 4 GB upload. What happens next?

High-level design

Build the design one flow at a time; the deep dives then harden the parts an interviewer pushes on.

A creator uploads a big video

The upload API creates the video and hands out signed URLs; the bytes go from the phone to object storage.

The app calls start; the upload API creates the video as uploading and returns URLs for the first parts.
The app sends each part straight to object storage, a few at a time; after a drop, only the missing ones.
The app calls complete with the part list, and the upload API checks it.
The video becomes processing, a job goes on the queue, and the call returns 202.

Architecture diagramA creator uploads a big video from a phone

The upload API hands out permission; the bytes go from the phone straight to object storage, a part at a time, and completing the upload queues the processing.

Diagram as text

Components: Upload API (Service); Video records (SQL DB); Creator app (Client); Processing queue (Queue); Object storage (Object store). Connections: Creator app → Upload API (1. start, 3. complete); Creator app → Object storage (2. each part, signed); Upload API → Video records (4. status: processing); Upload API → Processing queue (5. processing job), asynchronous.

Read:Learn: Large file upload & blob handling Learn: S3 / Blob Storage

Try it: Upload and play, end to endGuided practice · Video streaming, Video platform · Senior

Check yourself

Why don't the parts go through the upload API?
Show answerHide answer
Hundreds of gigabits a second of uploads would tie the API servers up; signed URLs let storage take the bytes while the API only grants permission.

A viewer presses play

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

The playback API answers a small question, and the CDN does the heavy lifting.

At the busiest time about 60 million people watch, roughly 180 Tbps: more than storage or servers in a few regions could send, or deliver across continents within two seconds. The edges send almost all of it.

Where the video bytes come from

Compared on	Straight from storage	Our streaming servers	A CDN, token in the cache key	A CDN, token checked, key on the path
Who sends the busiest hour	Storage, from a few regions	Our servers	Storage, since every play misses	The edges
A viewer far away waits	Too long	Too long	For a slow first fetch	About two seconds
Private videos	Signed URLs	Checked per request	Checked, at a huge cost	Checked at the edge
Pick it when	Not for video	Not for video

Private videos, one cached copy

A private video needs a signed token, but the cache must still share one copy among every allowed viewer.

A cache picks a stored response by its cache key, at least the method and the full URL (RFC 9111 (opens in a new tab)). A per-viewer token in that key makes every viewer miss; CloudFront's guide, for example, warns that highly variable values in the key can cache duplicate objects, lower the hit ratio and increase origin requests (CloudFront (opens in a new tab)). So the edge checks the token first, as CloudFront does with signed URLs (CloudFront (opens in a new tab)), then keys the file on its path.

Architecture diagramPrivate videos, one cached copy

Design YouTube

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

Which stores

The API

A resumable session works too

High-level design

A creator uploads a big video

A viewer presses play

Private videos, one cached copy

Sign in with Google to read the rest

Practise this

A CDN, or an edge network of your own?

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

Which stores

04The API

A resumable session works too

05High-level design

A creator uploads a big video

A viewer presses play

Private videos, one cached copy

Sign in with Google to read the rest

12Practise this

A CDN, or an edge network of your own?

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this