Hamropedia

Phase 8 · High-level design questions · Topic 8.6

Design a video streaming platform (like YouTube or Netflix)

Must knowHLD

Upload, process and stream videos to millions of viewers.

By Manoj Kumar Thapa

AI Software Engineer ·

Not started

Step 1 Understand it

Why interviewers ask this. It tests large-file handling, background processing pipelines, and adaptive — dealing with petabytes, not just .

Watch it happen

AnimationVideo: upload, transcode into segments, stream from a CDN
Read the animation as text
  1. The app gets a pre-signed URL and uploads the video in parts, straight to object storage — never through your servers.
  2. An event on a queue triggers transcoding workers.
  3. They cut the video into short segments of a few seconds, and encode each one at several qualities. A manifest lists every segment for every quality.
  4. Playback: the player fetches the manifest and segments from a CDN near the viewer, starting at a good quality.
  5. The viewer's bandwidth drops. For the NEXT segment the player simply asks for a lower quality — no stall. That is adaptive bitrate. View counts are added up later, in the background.

Requirements

Functional

  • Upload videos and process them into several resolutions.
  • Stream with quality that adapts to the viewer's connection; search and view details.
  • View counts and likes.

Non-functional

  • Smooth playback worldwide; enormous .
  • Uploads are never lost; processing may take minutes.
  • Reads are .

Estimates

  • 5 million daily viewers × 5 videos × about 300 ≈ 7.5 PB of video sent a day — which is why CDNs are essential.

API

  • POST /videos → pre-signed upload URL
  • GET /videos/{id} → details and manifest URL

Data model

  • videos (id, owner_id, title, status, manifest_url)
  • Raw and encoded files in .

Start simple, then scale

  1. Version 1: upload a file to a and serve it as it is.
  2. Version 2: files in object storage, details in a .
  3. Version 3: a pipeline driven by a , producing several qualities.
  4. Version 4: with or DASH, , CDN delivery, and view counts in the background.

Picture it

flowchart LR
  U["Uploader"] -->|"pre-signed URL"| RAW[("Raw video<br/>object storage")]
  RAW -->|"event"| Q[["Queue"]] --> T["Transcoding workers<br/>segments × qualities"]
  T --> ENC[("Encoded segments<br/>and manifest")]
  ENC --> CDN["CDN"] --> V["Viewers<br/>adaptive bitrate"]
Upload, then convert in the background, then deliver from the CDN. Viewers' players pick the quality that suits their connection.

The design, step by step

  1. Upload: the gets a and uploads in parts straight to object storage.
  2. An on a queue triggers transcoding , which cut the video into short segments and encode several resolutions and bitrates (a graph of tasks).
  3. The outputs go to object storage, with a (HLS or DASH) listing the segments for each quality.
  4. Playback: the player fetches the manifest and segments from a CDN and switches quality as bandwidth changes (adaptive bitrate).
  5. Video details live in a database with a ; view counts are aggregated in the background.

Deep dives

  • Adaptive bitrate: small segments (2–10 seconds) at several qualities.
  • Transcoding runs in parallel per segment, with per task.
  • Popular videos sit on the CDN; rarely watched ones are served from .
  • Resumable uploads for big files.

Common mistakes

  • Streaming from your own servers instead of a CDN.
  • Transcoding inside the upload request.
  • One quality for every device and connection.

Step 2 Go further (free, optional)

Optional. The notes above are written to be enough on their own. These free resources give a second explanation and extra practice.

Step 3 Practise

Try each exercise yourself first: on paper, out loud or in code. Then open the answer and compare it with yours.

  1. ExplainSay it in plain words in under a minute, with no notes.

    Explain the pipeline from upload to playback in 2 minutes.

    Show answer

    Upload: the app asks the for a pre-signed upload URL and sends the video straight to object storage, in parts, so a dropped connection resumes instead of restarting. The API records the video as "processing".

    Processing: the upload triggers an event on a queue. Transcoding workers split the video into short segments (a few seconds each) and encode every segment at several qualities (say 240p up to 4K, each at its own bitrate). This is a graph of tasks: split, encode in parallel, package. Each task is retried on its own if it fails. Thumbnails are made too.

    Output: the encoded segments go into object storage, along with a manifest file (HLS or DASH) that lists, for each quality, the segment files in order. The video's status becomes "ready", with the manifest's URL.

    Playback: the player fetches the manifest and the segments from a CDN close to the viewer. It measures how fast segments arrive and picks the quality for the next one: if the connection slows, it drops to a lower bitrate without stopping (adaptive bitrate streaming). Views and likes are counted ; video details come from a database behind a cache.

  2. DrawSketch the diagram (or class diagram) from memory.

    Draw the upload, the transcoding pipeline, storage, the CDN and the player.

    Show answer

    Uploads and playback both bypass the API servers for the heavy bytes: uploads go straight to object storage, and playback comes from the CDN. The transcoding pipeline sits between the two, driven by a queue.

    text
    UPLOAD
Creator app ── 1. ask for an upload URL ──► API ──► Videos DB (status: processing)
     │ 2. upload in parts (pre-signed URL)
     ▼
Object storage: raw video
     │ 3. "video uploaded" event
     ▼
Queue ──► Transcoding pipeline
           split into segments
             ├─► encode 240p ┐
             ├─► encode 720p ├─ in parallel, retried per task
             └─► encode 4K   ┘
           package: HLS/DASH manifest + segments, thumbnails
     │
     ▼
Object storage: encoded segments ──► Videos DB (status: ready)

PLAYBACK
Viewer's player ── manifest + segments ──► CDN edge
     ▲                                       │ miss
     │ picks the quality for                 ▼
     │ each segment by bandwidth      Object storage (origin)
     └─────────────────────────────────────────┘

  3. ApplyUse it in a real design question and say exactly where it fits.

    Estimate the storage for one 10-minute video encoded at 4 qualities: 0.5, 1, 3 and 6 .

    Show answer

    Storage = bitrate × duration. 10 minutes is 600 seconds; bitrates are in megabits a second, so divide by 8 for megabytes.

    • 0.5 Mbps: 37.5 MB
    • 1 Mbps: 75 MB
    • 3 Mbps: 225 MB
    • 6 Mbps: 450 MB

    Total: 787.5 MB, about 0.8 GB for one 10-minute video, and about 2.4 GB with 3 copies for . Add the original upload (often kept, at a high bitrate) and thumbnails. Notice that the top quality alone is more than half the total, which is why rarely watched videos are sometimes kept only at lower qualities, or re-encoded on demand.

    python
    seconds = 10 * 60
bitrates_mbps = [0.5, 1, 3, 6]
megabytes = [rate * seconds / 8 for rate in bitrates_mbps]   # megabits → megabytes
print(megabytes)                          # [37.5, 75.0, 225.0, 450.0]
print(sum(megabytes), sum(megabytes) * 3) # 787.5 2362.5: MB once, and with 3 copies

  4. Trade-offsSay what it costs, when not to use it, and the alternative.

    Build your own CDN (like Netflix) or use a commercial one?

    Show answer

    Use a commercial CDN (Akamai, Cloudflare, Amazon CloudFront…), and build your own only at Netflix's scale.

    Commercial CDN:
    • Global reach on day one, paid per gigabyte, with nothing to build or run.
    • Proven security and protection.
    • Downsides: at enormous volume, per-gigabyte prices add up to a very large bill, and you have less control over caching, placement and hardware. Many large companies use several CDNs at once, for price and resilience.

    Your own CDN (Netflix's Open Connect puts its own servers inside internet providers' networks):
    • At the scale where you are a large share of all internet traffic, owning the boxes is far cheaper per gigabyte.
    • Full control: tomorrow's popular shows are copied to the boxes overnight, when networks are quiet; tuned hardware and software.
    • Downsides: huge upfront cost, agreements with thousands of internet providers, teams to run hardware around the world, and years to build.

    It only pays off when traffic is huge, predictable, and mostly a known catalogue that can be placed in advance, which describes Netflix and very few others.

Step 4 Interview-ready, then prove it

Your interview answer

About 20 to 40 seconds, said out loud. Practise it until it sounds like you, not like notes.

Uploads go straight to object storage with pre-signed URLs. A queue triggers transcoding workers that encode short segments at several bitrates and write HLS or DASH manifests. Viewers stream the segments from a CDN with adaptive bitrate. Video details live in a database behind a cache, and view counts are aggregated in the background.

Follow-up questions

Why split videos into segments?

Segments can be transcoded in parallel, cached by the CDN, and let the player switch quality in the middle of a video.

How do you count views at this scale?

Send view events to a stream, aggregate them in batches, and update the stored total periodically.

Tick each check when you can do it without notes

A topic is finished when you pass all four checks, not when you finish a video. Be strict: if you needed your notes, it is not ticked yet.

  • Explain Say it in plain words in under a minute, with no notes.
  • Draw Sketch the diagram (or class diagram) from memory.
  • Apply Use it in a real design question and say exactly where it fits.
  • Trade-offs Say what it costs, when not to use it, and the alternative.

0 of 4 checks ticked.

Saved in this browser. Back it up or move it to another device.