Understanding the problem
YouTube is a video-sharing platform: users upload, view, and interact with video. As of this writing it is among the most visited sites on the web. There is conceptual overlap with designing Dropbox — if you are less familiar with file upload/download system design, start with that guide first.
Presigned multipart.
Segments + formats.
ABR + manifest.
CDN + meta cache.
Pair with Delivery framework, Design Dropbox, Handling large blobs, Long-running tasks, and Scaling reads.
Functional requirements
Non-functional requirements
Planning the approach
Before drawing boxes, plan: build the design sequentially through functional requirements, then use NFRs to drive deep dives. Stay focused — do not get lost in search or recommendations.
Core entities
Start with a broad overview — not every column. Align vocabulary with the interviewer.
The API
Define an endpoint per functional requirement early — then expect APIs to evolve as trade-offs appear. Say that out loud: "I'll outline simple APIs and may revise them as we go deeper."
Background: video streaming basics
You do not need to be a video engineer. You do need vocabulary so you can navigate trade-offs.
1) Users can upload videos
When uploading, pin three questions: where is metadata? where are bytes? what do we store for video data?
~1M uploads/day → ~365M video rows/year. Prefer a horizontally partitioned store such as Cassandra, partitioned by videoId — we mostly do point lookups, not bulk scans. Partitioning matters when you need co-located reads or domain consistency (e.g. Ticketmaster by concert); here point lookup by videoId is enough.
For bytes, reuse the Dropbox lesson: upload directly to S3 via a presigned URL with multipart upload. That changes POST /upload → POST /presigned_url (metadata only).
What to store for video data
2) Users can watch videos
Fetch VideoMetadata (manifest URL(s)). Evolve GET /video to return metadata only — bytes live in object storage / CDN.
Segmented storage is not the same as "chunked HTTP download of one file." Some formats happen to be playable when read in order; playable segments make incremental playback explicit and unlock ABR.
ABR client loop
- Fetch VideoMetadata → URL to primary manifest in S3/CDN.
- Download the manifest.
- Choose a format from network / user settings; pull first segment URL from the media manifest.
- Play; prefetch more segments.
- If bandwidth worsens (or improves), switch to lower (or higher) bitrate segments without stopping playback.
Deep dive: processing for ABR
Smooth playback needs ABR, which needs segments + formats + manifests produced after upload. Post-processing is a pipeline.
- Split the original into segments (e.g. ffmpeg).
- Transcode each segment (and related work: audio, transcripts) — parallel across workers.
- Create manifests referencing formats / segments.
- Mark the upload complete; update VideoMetadata.
Work forms a DAG: one-way dependencies, fan-out on independent segment transcodes (CPU-bound — parallelize hard). Orchestrate with something like Temporal. Pass temporary artifacts via S3 URLs between workers — do not ship multi-GB blobs through the orchestrator.
Deep dive: resumable uploads
Strong overlap with Dropbox large-file upload. Track progress of the original upload:
- Client divides the file into ~5–10MB chunks with fingerprint hashes.
- VideoMetadata stores
chunks[]with fingerprint + status (NotUploaded/Uploaded). - Client POSTs chunk list, then uploads parts to S3.
- S3 returns part number + ETag; client PATCHes the backend so the server can verify and mark the chunk Uploaded.
- On
CompleteMultipartUpload, S3 emits an object-created notification once — kick processing. Chunk progress remains client-driven as above. - On resume: fetch metadata, skip already-Uploaded chunks.
In practice this is AWS multipart upload — naming the steps shows depth.
Deep dive: scale (1M upload / 100M watch)
Hot video metadata: raise RF so several nodes share load; add a distributed LRU cache partitioned by videoId in front of Cassandra.
Geo latency: CDN caches popular manifests and segments near users. Once warm, streaming may never touch your origin for the rest of playback.
Upload Monitor (Lambda): S3 part/object events can also drive an upload monitor that writes chunk progress into VideoMetadata — complements client-driven resume tracking from the resumable-uploads deep dive.
Final design
What is expected at each level?
Mid: solid spine + coachable on blobs/segments. Senior: own processing DAG + multipart resume + ABR. Staff+: anticipate hot spots, CDN, and readiness races like you've shipped them.
Wrapping up
YouTube's interview spine is control plane vs data plane for video: metadata + presigns on your service, durable originals on S3, a DAG that turns one file into segments + manifests, and ABR clients that fetch quality-appropriate clips from a CDN — with resumable multipart for tens of GB and caches for viral metadata reads.
Related: Delivery framework · Design Dropbox · Handling large blobs · Long-running tasks · Scaling reads · Caching · Common patterns.