system-design · intermediate

Design YouTube — Upload, Process, and Stream Video

Start here

Design YouTube (simplified):

1. Creators upload videos
2. System processes multiple resolutions
3. Viewers stream playback worldwide with low startup time
4. Metadata: title, thumbnails, views (approx OK)

What you will learn

1. Scope MVP vs recommendations/live.
2. Design resumable upload to object storage.
3. Build transcoding pipeline with workers/queues.
4. Serve adaptive bitrate via CDN.
5. Handle popularity hotspots and thumbnails.
6. Discuss consistency of view counts.

Words you need before we begin

Requirements

MVP

• Upload video
• Process 360p/720p/1080p
• Playback
• Basic channel/video metadata
• View count approximate

Non-functional

• Upload reliability for multi-GB files
• Global playback latency
• Cost awareness (egress + encode)

High-level design

flowchart LR
  Creator --> API
  Creator --> Upload[Presigned upload]
  Upload --> Raw[(Raw object store)]
  API --> Q[Transcode queue]
  Q --> W[Workers]
  W --> Out[(Processed renditions)]
  Viewer --> CDN --> Out
  API --> Meta[(Metadata DB)]

Step-by-step design

Step 1 — Upload

Resumable chunked upload to raw bucket; complete event triggers processing.

Step 2 — Transcode workers

Workers pull jobs; ffmpeg-like processing; write renditions + HLS playlists; update status PROCESSING → READY.

Step 3 — Metadata

Video id, owner, title, duration, status, playback URLs, thumbnail URLs.

Step 4 — Playback

Player fetches master playlist via CDN; segments cached at edge.

Step 5 — Popularity

Hot videos naturally CDN-cached. Protect origin with cache TTLs and rate limits on miss storms.

Step 6 — Thumbnails & previews

Async generation; store as images on CDN.

Step 7 — View counts

Async events to stream/counter service; eventual accuracy OK; do not lock video row per view.

Failure modes

Trade-offs

Common mistakes

1. App server streams every playback byte.
2. No async pipeline.
3. Perfect recommendation ML first.
4. Strongly consistent global view count.
5. Ignoring cost of egress and encoding.

Check your understanding

1. Why presigned upload to object storage?
2. What does a transcode worker output?
3. How does ABR use playlists?
4. Why eventual view counts?
5. How do hot videos avoid melting origin?

Practice

1. Estimate storage if 1M hours uploaded/day at multiple bitrates.
2. Draw states: uploaded → processing → ready → failed.
3. Design priority queue for paid creators.
4. Discuss DRM at a high level (mention only).
5. Mock interview.

Deeper production notes

Idempotent jobs

Processing must tolerate redelivery without spawning infinite duplicate renditions—content-addressed outputs help.

Cold storage

Move rarely watched originals to colder storage classes.

Additional teaching scenarios

Scenario A — 10× peak

Scenario B — dependency down 30 minutes

Scenario C — interview wrap (5 sentences)

Revision summary

• Upload → async process → CDN play.
• Metadata separate from media plane.
• Scale processing with queues/workers.
• Approximate counters for hot metrics.

Glossary

Abbreviations and terminology

• HLS — HTTP Live Streaming
• DASH — Dynamic Adaptive Streaming over HTTP
• CDN — Content Delivery Network

What to learn next

1. CDN
2. Message queues
3. File upload service design

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Extra teaching notes

When you apply this lesson, write the user-visible success metric first, then the failure mode you fear most. Design the smallest mechanism that protects that metric under partial failure. Prefer explicit timeouts, idempotency, and ownership over adding more infrastructure boxes.

In interviews or design reviews, narrate assumptions, request paths, and trade-offs out loud. A correct-enough design with clear failure handling beats a buzzword diagram without numbers. Revisit the worked example and restate it for a different domain to prove you own the ideas, not the template wording.

Interview and production field guide for this topic

Use this section as deliberate practice, not filler. Rewrite the worked example for a second domain you know well—fintech, education, logistics, or media. Keep the same skeleton: requirements, estimates, high-level diagram, request path, data model, scale lever, failure modes, and trade-offs. If you cannot fill every section without copying buzzwords, you do not yet own the design.

Numbers to force yourself to state

Always speak order-of-magnitude figures: peak QPS, storage growth per day, fan-out factor, connection counts, or queue depth. Wrong numbers that are explicit beat silent hand-waving. Correct the numbers when the interviewer or teammate challenges them; that is collaboration, not failure.

Failure minute

Set a timer for sixty seconds and list only failures: timeouts, duplicates, hot keys, dependency outages, bad deploys, and data corruption paths. For each, name detection and first mitigation. Designs that only describe the happy path are incomplete for production and weak in interviews.

Ownership and operability

Name the dashboard, the alert, the runbook section, and the team that pages. If any are blank, the system will train you during an incident. Prefer progressive delivery: canaries, flags, and rollback notes written before the change lands.

Consistency and retries

State whether the design assumes at-least-once delivery, whether handlers are idempotent, and where unique constraints live. Retries without idempotency are how double charges, double messages, and duplicate fan-out jobs appear. Timeouts without bounds are how thread pools die.

What good looks like in a review

A strong design review or interview answer clarifies scope, makes assumptions audible, draws a minimal path, deepens one or two bottlenecks, and closes with trade-offs and evolution. Use that bar on design-youtube round 0 every time you revisit it.

Interview and production field guide for this topic

Use this section as deliberate practice, not filler. Rewrite the worked example for a second domain you know well—fintech, education, logistics, or media. Keep the same skeleton: requirements, estimates, high-level diagram, request path, data model, scale lever, failure modes, and trade-offs. If you cannot fill every section without copying buzzwords, you do not yet own the design.

Numbers to force yourself to state

Always speak order-of-magnitude figures: peak QPS, storage growth per day, fan-out factor, connection counts, or queue depth. Wrong numbers that are explicit beat silent hand-waving. Correct the numbers when the interviewer or teammate challenges them; that is collaboration, not failure.

Failure minute

Set a timer for sixty seconds and list only failures: timeouts, duplicates, hot keys, dependency outages, bad deploys, and data corruption paths. For each, name detection and first mitigation. Designs that only describe the happy path are incomplete for production and weak in interviews.

Ownership and operability

Name the dashboard, the alert, the runbook section, and the team that pages. If any are blank, the system will train you during an incident. Prefer progressive delivery: canaries, flags, and rollback notes written before the change lands.

Consistency and retries

State whether the design assumes at-least-once delivery, whether handlers are idempotent, and where unique constraints live. Retries without idempotency are how double charges, double messages, and duplicate fan-out jobs appear. Timeouts without bounds are how thread pools die.

What good looks like in a review

A strong design review or interview answer clarifies scope, makes assumptions audible, draws a minimal path, deepens one or two bottlenecks, and closes with trade-offs and evolution. Use that bar on design-youtube round 1 every time you revisit it.

FAQ from first-time learners

Q: Where is the video “database”?
A: Bytes in object storage; metadata in DB; playback via CDN.

Q: Do I design codecs?
A: No—name requirements (multiple bitrates) and pipeline.

Track: Distributed Systems

Previous: Design WhatsApp — 1:1 and Group Messaging

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab