Design a Video Streaming Platform

TL;DR

Build Netflix/YouTube -- a system that ingests video uploads, transcodes them into multiple resolutions and codecs, stores the outputs, and streams them to millions of concurrent viewers with adaptive bitrate switching. The transcoding pipeline is a DAG (directed acyclic graph): split the video into chunks, encode each chunk in parallel across dozens of workers, merge the results. Netflix's per-shot encoding with VMAF (Video Multi-Method Assessment Fusion) quality metric saves 20% bandwidth by varying the bitrate based on scene complexity -- an explosion scene gets more bits than a dialogue scene. Google's Global Cache (GGC) places servers inside ISP data centers, eliminating the last-mile bottleneck for popular content. YouTube ingests 500 hours of video every minute. The system design challenge is the upload-to-playable pipeline, not the playback protocol.

The System

Netflix. A user opens the app on their 4K TV, selects a movie, and playback starts within 2 seconds. The video looks flawless. When their bandwidth drops because someone else starts downloading on the same Wi-Fi, the video quality silently decreases to avoid buffering. When bandwidth recovers, quality increases again. The user notices nothing.

Behind this seamless experience: the original movie was a 200 GB master file. Netflix transcoded it into 120+ different versions (combinations of resolution, bitrate, codec, and audio language). These versions are stored on thousands of CDN servers worldwide. The player downloads the version that matches the current bandwidth, switching between versions every 4 seconds (one segment) if conditions change. This is Adaptive Bitrate (ABR) streaming, and it is the foundation of every video platform.

YouTube is a different beast. While Netflix deals with ~17,000 titles (manageable catalog, premium content), YouTube has over 800 million videos and receives 500 hours of new uploads every minute. YouTube must transcode this firehose of user-generated content quickly (hours, not days), store it cost-efficiently (most videos get < 100 views), and serve the tiny fraction of viral content to millions simultaneously.

Requirements

Functional Requirements

Requirement	Details
Video upload	Users upload videos in any format (MP4, MOV, AVI, MKV). Up to 12 hours long.
Transcoding	Convert uploaded video into multiple resolutions (360p, 480p, 720p, 1080p, 4K) and codecs (H.264, H.265, VP9, AV1).
Streaming	Adaptive bitrate streaming via HLS or DASH. Playback starts within 2 seconds.
Content delivery	Low-latency delivery worldwide via CDN.
Metadata	Title, description, thumbnails (auto-generated + custom), subtitles, chapters.
Recommendations	Not in scope for this question (but the video catalog is the data source).

Non-Functional Requirements

Requirement	Target
Upload-to-playable latency	< 1 hour for a 10-minute video (YouTube). < 24 hours for a feature film (Netflix).
Playback start time	< 2 seconds (time to first frame)
Rebuffering ratio	< 0.5% of playback time
Availability	99.99% for playback. 99.9% for uploads.
Scale	500 hours uploaded/min (YouTube), ~30M concurrent streams (Netflix peak)

Back-of-Envelope Math

YouTube uploads:
  500 hours/min = 30,000 hours/day
  Average uploaded video:     10 minutes, 500 MB (1080p)
  Daily upload volume:        500 hr/min * 60 min * 500 MB/10 min = 1.5 PB/day raw

Transcoding output per video:
  360p:  50 MB
  480p:  100 MB
  720p:  250 MB
  1080p: 500 MB (same as original)
  4K:    2 GB
  Total per video:            ~3 GB (for all resolutions, one codec)
  With 3 codecs:              ~9 GB per video
  Videos per minute:          500 hours/min = 500 * 6 = 3,000 ten-minute videos per minute
  Daily transcoding output:   3,000 videos/min * 9 GB = 27 TB/min = 38.9 PB/day of transcoded output

Storage:
  Total YouTube videos:       800 million
  Average storage per video:  ~5 GB (all renditions, reduced by not encoding all resolutions for unpopular content)
  Total storage:              4 exabytes (yes, exabytes)

Netflix numbers:
  Catalog:                    ~17,000 titles
  Average movie:              200 GB master
  120+ renditions per title:  ~50 GB stored per title (compressed)
  Total Netflix storage:      ~850 TB (tiny compared to YouTube)

Streaming bandwidth:
  Netflix peak:               ~30M concurrent streams
  Average bitrate:            5 Mbps
  Peak bandwidth:             30M * 5 Mbps = 150 Tbps
  This is ~15% of all US internet traffic during peak hours

The number that should alarm you: 38.9 PB/day of transcoding output for YouTube. This is an astonishing amount of compute. YouTube reportedly runs one of the largest computing clusters in the world just for transcoding.

Naive Design

Upload video. Transcode on one server. Store on disk. Stream via HTTP.

Upload:

POST /api/upload
Body: video file (chunked upload for large files)
Server stores to local disk.

Transcode (single machine, sequential):

for resolution in [360, 480, 720, 1080, 2160]:
    for codec in ['h264', 'h265', 'vp9']:
        ffmpeg -i input.mp4 -vf scale=-1:{resolution} -c:v {codec} output_{resolution}_{codec}.mp4

Stream:

GET /video/{video_id}/{resolution}.mp4
Server reads file from disk, returns it.

A 1-hour video at 1080p takes ~20 minutes to transcode with H.264 on a modern server. With 15 resolution/codec combinations, that is 5 hours of transcoding for one video. At 3,000 new videos per minute, you need 900,000 hours of transcoding per minute. On one server.

Where It Breaks

Problem 1: Sequential Transcoding Is Impossibly Slow

One server transcodes one video at one resolution at a time. A 1-hour video takes 5 hours for all renditions. YouTube receives 3,000 videos per minute. Sequential transcoding would need 1 million servers to keep up.

Problem 2: Progressive Download Is Not Adaptive

Serving the video as a single HTTP download (GET /video.mp4) means the player downloads the entire file before playing (or at best, starts playing after buffering). If bandwidth drops, the player buffers. There is no way to switch to a lower resolution mid-playback.

Problem 3: Single-Server Delivery Does Not Scale

30 million concurrent Netflix streams at 5 Mbps each. That is 150 Tbps. No single data center has that bandwidth. You need content distributed across thousands of edge servers worldwide.

Problem 4: Storage Costs Are Catastrophic

If you transcode every YouTube upload into all 15 renditions, you store 9 GB per 10-minute video. 99% of YouTube videos get fewer than 100 views. Storing 4K renditions for a video that 3 people watch is wasting money.

Problem 5: No Error Recovery

If transcoding crashes 90% through a 5-hour job, you start over from the beginning. The video is delayed by 10 hours instead of 5.

Real Design

Video Streaming — Video Streaming High-Level Design

Architecture Overview

┌──────────────┐
│  Upload      │
│  Service     │ ── chunked upload to object storage (S3)
└──────┬───────┘
       │ (upload complete event)
┌──────┴───────┐
│  Transcoding │
│  Orchestrator│ ── creates DAG of transcoding tasks
└──────┬───────┘
       │
┌──────┴───────────────────────────────────┐
│  Transcoding Worker Pool                  │
│  ┌────────┐ ┌────────┐ ┌────────┐        │
│  │Worker 1│ │Worker 2│ │Worker N│        │
│  │(chunk 1│ │(chunk 2│ │(chunk M│        │
│  │ 1080p) │ │ 1080p) │ │ 720p)  │        │
│  └────────┘ └────────┘ └────────┘        │
└──────┬───────────────────────────────────┘
       │
┌──────┴───────┐     ┌──────────────┐
│  Merge &     │     │  Metadata    │
│  Package     │     │  Service     │
│  (HLS/DASH)  │     │  (thumbnails,│
│              │     │   subtitles) │
└──────┬───────┘     └──────────────┘
       │
┌──────┴───────┐
│  Origin      │
│  Storage     │ ── S3 / Google Cloud Storage
│  (segments)  │
└──────┬───────┘
       │
┌──────┴───────┐
│  CDN         │ ── CloudFront, Google GGC, Netflix Open Connect
│  (edge cache)│
└──────┬───────┘
       │
┌──────┴───────┐
│  Player      │ ── ABR algorithm selects quality per segment
│  (client)    │
└──────────────┘

Component 1: The Transcoding DAG

Transcoding a video into 15 renditions sequentially takes 5 hours. A DAG (directed acyclic graph) pipeline parallelizes this.

Step 1: Split (5 minutes)

Split the source video into 4-second chunks at GOP (Group of Pictures) boundaries. A 1-hour video becomes ~900 chunks. Each chunk is independently decodable (starts with a keyframe).

Why GOP boundaries? If you split mid-GOP, the chunk starts without a keyframe and cannot be decoded independently. GOP-aligned splitting ensures each chunk is self-contained.

Step 2: Encode in parallel (variable, ~10 minutes wall clock)

Each chunk is encoded independently into each resolution/codec combination. 900 chunks * 15 renditions = 13,500 encoding tasks. These tasks run on a pool of transcoding workers (typically GPU-accelerated).

Chunk 1 -> [360p/H.264, 480p/H.264, 720p/H.264, 1080p/H.264, ...]
Chunk 2 -> [360p/H.264, 480p/H.264, 720p/H.264, 1080p/H.264, ...]
...
Chunk 900 -> [same]

Each individual encoding task takes ~1-5 seconds for a 4-second chunk. With 1,000 workers, 13,500 tasks complete in ~14 rounds of 1,000 tasks each * 3 seconds = 42 seconds of encoding time. Including split (~5 min), merge (~2 min), and packaging (~1 min), the total wall-clock time for a 1-hour video drops from 5 hours sequential to roughly 9 minutes end-to-end.

Step 3: Merge (2 minutes)

Concatenate the encoded chunks back into full renditions. Verify A/V sync. Generate the HLS manifest or DASH MPD (Media Presentation Description) file that lists all segments and their URLs.

Step 4: Package (1 minute)

Create the HLS .m3u8 playlist files and DASH .mpd manifest. Upload segments and manifests to origin storage.

Error recovery: If a worker crashes while encoding chunk 437 at 720p, only that one task is retried. The other 13,499 tasks are unaffected. The DAG orchestrator (Apache Airflow, AWS Step Functions, or a custom scheduler) tracks task status and retries failed tasks.

Component 2: Adaptive Bitrate Streaming (ABR)

ABR is the protocol that makes modern video streaming work. Instead of downloading one video file, the player downloads small segments (2-10 seconds each) and chooses the quality for each segment based on current bandwidth.

HLS (HTTP Live Streaming, Apple):

Master playlist:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
360p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
480p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p/playlist.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/playlist.m3u8

Segment playlist (720p):

#EXTM3U
#EXT-X-TARGETDURATION:4
#EXTINF:4.000,
segment_001.ts
#EXTINF:4.000,
segment_002.ts
...

DASH (Dynamic Adaptive Streaming over HTTP, MPEG):

Similar concept, XML-based manifest (MPD). Industry standard, not Apple-specific.

ABR algorithm (client-side):

On each segment download:
  measured_bandwidth = segment_size / download_time
  buffer_level = seconds of buffered video remaining

  if buffer_level < 5 seconds:
    // Low buffer. Switch down aggressively to avoid rebuffering.
    select lowest quality where bitrate < measured_bandwidth * 0.5
  elif buffer_level > 30 seconds:
    // Full buffer. Try switching up.
    select highest quality where bitrate < measured_bandwidth * 0.8
  else:
    // Maintain current quality if bandwidth is sufficient.
    if current_bitrate < measured_bandwidth * 0.7:
      stay at current quality
    else:
      switch down one level

The 0.8 multiplier: You do not use 100% of measured bandwidth for the next segment. Bandwidth fluctuates. Using 80% of measured bandwidth provides a safety margin to avoid rebuffering.

Component 3: Netflix Per-Shot Encoding with VMAF

Standard encoding uses a fixed bitrate for the entire video. Netflix realized this wastes bits: a dark dialogue scene compresses well at 500 kbps, while an action sequence with explosions needs 4,000 kbps to look good.

Per-shot (per-scene) encoding:

Scene detection: Split the video into "shots" (segments with visually similar content, typically 1-15 seconds). Netflix uses a perceptual hash to detect scene changes.
Trial encoding: For each shot, encode at multiple bitrates (200 kbps, 500 kbps, 1000 kbps, ... 8000 kbps).
VMAF scoring: Score each trial with VMAF (Video Multi-Method Assessment Fusion), Netflix's perceptual quality metric. VMAF correlates better with human perception than PSNR or SSIM. A VMAF score of 93+ is "good enough" -- most viewers cannot distinguish it from the original.
Bitrate selection: For each shot, select the lowest bitrate that achieves VMAF >= 93. Dark dialogue at 500 kbps might score VMAF 95. Explosions at 500 kbps score VMAF 60; you need 3,000 kbps.
Variable bitrate file: The final encoded file varies its bitrate per shot. The average bitrate drops ~20% compared to constant bitrate encoding with the same perceptual quality.

Impact: Netflix saves 20% of CDN bandwidth. At 30M concurrent streams * 5 Mbps = 150 Tbps, 20% savings = 30 Tbps. At CDN egress costs of ~$0.01/GB, the savings are significant.

Why this is a system design question: Per-shot encoding requires encoding the video MULTIPLE times per shot (for trial encodings), which increases compute cost by 5-10x. Netflix decided the bandwidth savings justify the compute cost. This is a trade-off you should discuss.

Component 4: Content Delivery -- Google Global Cache and Netflix Open Connect

Streaming 150 Tbps from a single data center is impossible. CDN edge servers bring content close to users.

Traditional CDN (CloudFront, Akamai):

~300 Points of Presence (PoPs) worldwide.
When a user requests a video segment, the CDN checks its edge cache. On cache hit (the segment is already stored at the edge), serve directly. On cache miss, fetch from origin (S3), cache at the edge, and serve.
Cache hit ratio for popular content: ~95%. For long-tail content: ~30%.

Google Global Cache (GGC):

Google goes further. GGC servers are placed inside ISP data centers. The ISP provides rack space and power. Google provides the servers and content.

User requests a YouTube video. DNS resolves to the GGC server inside their ISP.
The GGC server has the video cached (because many users on that ISP have watched it).
The video is served from within the ISP's network. Zero internet backbone traffic.
ISP benefits: reduced peering costs (video is 60%+ of internet traffic). Google benefits: lower latency, lower CDN costs.

Netflix Open Connect:

Netflix operates its own CDN called Open Connect. They ship custom appliances (servers with 100+ TB of storage) to ISPs worldwide. Over 1,000 ISPs host Open Connect appliances.

During off-peak hours (2-6 AM), Open Connect appliances download the content catalog (or the most popular portion of it) from Netflix's origin in AWS.
During peak hours, 95%+ of Netflix traffic is served from Open Connect appliances inside the ISP, not from AWS.
Netflix pays for the appliance hardware (~$20K each). The ISP provides rack space, power, and network connectivity.

Component 5: Storage Tiering for Cost Optimization

YouTube's 4 exabytes of storage cannot all be on fast, hot storage. Most videos are rarely watched.

Tiering strategy:

Hot tier (first 7 days):
  All renditions stored on SSD-backed storage.
  Fastest access. Highest cost ($0.023/GB/month for S3 Standard).

Warm tier (7 days - 6 months):
  Popular videos: all renditions on standard storage.
  Unpopular videos: only 360p and 720p. Higher resolutions deleted.
  Re-transcode from original if user requests 1080p. (Rare for unpopular videos.)

Cold tier (> 6 months, < 100 views):
  Only 360p rendition stored. Original source retained in Glacier ($0.004/GB/month).
  Re-transcode on demand if the video goes viral (rare but possible).

Archive tier (> 2 years, < 10 views):
  Only original source in Glacier Deep Archive ($0.00099/GB/month).
  Takes 12-48 hours to retrieve.

Savings: Storing 4 EB at S3 Standard: $92M/month. With tiering: ~$15M/month. The savings pay for the re-transcoding compute when cold content is occasionally requested.

Deep Dives

Code Judge Sandbox

Deep Dive 1: The Upload Pipeline for 500 Hours/Minute

Ingesting 500 hours of video per minute requires a robust upload pipeline.

Chunked upload:

Client splits the file into 5 MB chunks.
Each chunk is uploaded independently via PUT /upload/{upload_id}/chunk/{n}.
Server stores chunks in S3 with multipart upload.
On final chunk, the server triggers a completion event.
If the upload fails mid-way (network drop), the client resumes from the last successful chunk. No need to re-upload the entire file.

Validation:

File format detection (magic bytes, not extension -- users upload .mp4 files that are actually .avi inside).
Virus/malware scan (run in a sandboxed container).
Duration check (reject > 12 hours unless the uploader is whitelisted).
Copyright detection (Content ID for YouTube -- hash the audio and compare against a database of copyrighted content).

Upload rate: 3,000 videos/min * 500 MB avg = 1.5 TB/min = 25 GB/sec ingest rate. This is distributed across upload servers worldwide. Each upload server handles ~100 concurrent uploads. 250 upload servers handle the load.

Deep Dive 2: Codec Wars -- H.264 vs. H.265 vs. AV1

The codec choice dramatically affects quality, bandwidth, and compute cost.

Codec	Compression	Encode Speed	Decode Support	License
H.264 (AVC)	Baseline (1x)	Fast (1x)	Universal (99%+ devices)	Licensed ($)
H.265 (HEVC)	40% better	3-5x slower	85% of devices (limited Firefox support)	Licensed ($$$)
VP9 (Google)	30% better	2-3x slower	90% (Chrome, Android, smart TVs)	Royalty-free
AV1 (Alliance)	50% better	10-20x slower	60% (growing, new devices)	Royalty-free

Netflix strategy: Encode in H.264 (universal fallback) + AV1 (for supported devices). AV1 saves 50% bandwidth but costs 10x more to encode. Netflix can afford the compute because they encode each title once and serve it millions of times -- the per-view savings far outweigh the one-time encoding cost.

YouTube strategy: Encode in H.264 (immediate, fast) + VP9 (for Chrome and Android, 30% savings). AV1 for the most popular videos only (top 1% by views), because the encoding cost is justified by the view count.

System design impact: You must store multiple codec versions of each video. The player negotiates codec support with the server (via the manifest) and selects the best supported codec.

Deep Dive 3: Live Streaming vs. VOD

If the interviewer asks about live streaming, the architecture changes significantly.

VOD (Video on Demand): Transcode offline. Store segments. Serve from CDN cache. Latency tolerance: seconds.

Live streaming: Transcode in real time. Segments are created as the stream progresses. CDN cache is cold (every segment is new). Latency target: 3-30 seconds behind real-time.

Key differences:

No DAG parallelism: You cannot split a live stream into chunks and encode in parallel because the future chunks do not exist yet. You must encode sequentially, chunk by chunk.
Segment creation latency: Each 4-second segment must be encoded and available within ~2 seconds of capture. Total glass-to-glass latency: capture (0.5s) + encode (1-2s) + CDN propagation (0.5-1s) + player buffer (2-4s) = 4-8 seconds.
CDN cache miss rate: Every live segment is a cache miss at the CDN edge (nobody has requested it before). CDN must pull from origin for every segment. Origin must handle the full fan-out.

Mitigation: CDN shield layer. Instead of every edge PoP fetching from origin, a mid-tier cache layer (CDN shield) fetches once from origin and serves to all edges. Fan-out: origin serves 50 shield servers, each shield serves 100 edges. Origin load: 50 requests per segment instead of 5,000.

Alternative Designs

Approach	Pros	Cons	When to Use
DAG transcoding + ABR + CDN (described above)	Parallel encoding. Adaptive quality. Global delivery.	Complex pipeline. High compute cost.	Netflix, YouTube, any video platform.
Progressive download (single file)	Simple. Works everywhere.	No adaptive quality. Rebuffers on bandwidth drops. Large files download slowly.	Internal tools, small-scale video hosting.
WebRTC (peer-to-peer)	Ultra-low latency (< 500 ms). No CDN for small audiences.	Does not scale beyond ~50 viewers. No ABR.	Video calls, small live streams.
Third-party (Mux, Cloudflare Stream)	Fully managed transcoding and delivery. Zero infrastructure.	Cost per minute of video. Less control. Vendor lock-in.	Startups. When video is a feature, not the product.
On-the-fly transcoding	No pre-transcoding. Encode when requested. Zero storage for unpopular renditions.	High latency on first request. Requires real-time encoding capacity.	Very long-tail content where pre-transcoding is wasteful.

Scaling Math Verification

Transcoding Compute

Videos per minute:           3,000
Encoding tasks per video:    900 chunks * 15 renditions = 13,500 tasks
Total tasks per minute:      3,000 * 13,500 = 40.5M tasks/min
Task duration:               ~3 seconds avg
Worker-seconds per minute:   40.5M * 3 = 121.5M worker-seconds/min
Workers needed:              121.5M / 60 = 2.025M concurrent workers

That is 2 million transcoding workers. Is this realistic?

GPU-accelerated encoding:    One GPU handles ~50 concurrent encodes
GPUs needed:                 2.025M / 50 = 40,500 GPUs
At $0.50/hr per GPU (spot):  40,500 * $0.50 = $20,250/hr = $486K/day

Our estimate: ~$500K/day in GPU compute. This is a rough order of magnitude, not a public figure.

CDN Bandwidth

Netflix peak:                ~30M concurrent streams
Average bitrate:             5 Mbps
Total bandwidth:             150 Tbps
Open Connect cache hit rate: 95%
Origin bandwidth:            150 Tbps * 0.05 = 7.5 Tbps from AWS
AWS egress at list $0.05/GB:  937.5 GB/sec × $0.05 = ~$47/sec = ~$4M/day at list price.
                             Netflix negotiates rates orders of magnitude below this via Open Connect.

YouTube daily bandwidth:
  1B daily video views * 5 min avg * 3 Mbps avg
  = 5B minutes * 3 Mbps
  = 5B * 60 sec * 3 Mbps = 900 Pb/day
  = 10.4 Tbps average
  GGC hit rate ~90%: origin serves 1 Tbps

Storage

YouTube daily upload storage:
  3,000 videos/min * 5 GB (all renditions with tiering) = 15 TB/min = 21.6 PB/day

  With tiering (cold videos get fewer renditions):
    Day 1:        5 GB per video (all renditions)
    After 6 months: 1 GB per video (only 360p + original in Glacier)

  Annual storage growth: ~3 EB (after tiering)
  Storage cost (tiered):  ~$15M/month

Failure Analysis

Failure	Impact	Mitigation
Transcoding worker crash	One chunk encoding fails. Video is not fully processed.	DAG orchestrator detects failed task and retries on a different worker. Only the failed chunk is re-encoded, not the entire video.
Upload interrupted	User loses progress if not resumable.	Chunked upload with resume. S3 multipart upload retains uploaded parts for 7 days. Client resumes from last successful chunk.
CDN edge cache miss storm (new popular content)	Origin is overwhelmed. Users see buffering.	CDN shield layer absorbs the miss storm. Origin pre-pushes popular content to edges before release (Netflix does this for new releases).
ABR algorithm selects too high quality	Player downloads segment that cannot arrive in time. Rebuffering.	Conservative ABR: never use more than 80% of measured bandwidth. Buffer-based ABR: prefer lower quality when buffer is low.
Origin storage (S3) goes down	No new segments can be fetched. CDN serves stale cache.	CDN cache has 24-hour TTL for VOD content. S3 has 99.999999999% durability. Multi-region replication for origin.
Codec not supported on device	Video fails to play. Black screen.	Manifest lists multiple codec options. Player falls back to H.264 (universally supported). Server-side device detection as backup.
Copyright detection delays upload processing	Legitimate uploads are stuck in review. Creator frustrated.	Async copyright scan. Allow immediate processing; flag for review if match found. Remove AFTER review, not before.

Level Expectations

Level	What the Interviewer Expects
Mid (L4)	Upload -> transcode -> store -> serve. Mentions multiple resolutions. Knows about CDN. Basic understanding of segments and playlists.
Senior (L5)	DAG transcoding pipeline with parallel chunk encoding. ABR streaming (HLS/DASH) with client-side quality selection. GOP-aligned splitting. CDN with cache hit rate analysis. Storage tiering for cost optimization. Codec trade-offs (H.264 vs. H.265 vs. AV1).
Staff+ (L6)	Netflix per-shot encoding with VMAF quality metric. Google GGC / Netflix Open Connect inside ISP data centers. Live streaming vs. VOD architecture differences. CDN shield layer for miss storms. Quantified transcoding compute cost. Discussion of codec licensing and the AV1 alliance. Upload pipeline with Content ID copyright detection.

References from Our Courses

Kafka Partitions and Ordering — event-driven transcoding pipeline orchestration
Distributed File Systems — chunked storage for video segments
API Gateway Responsibilities — CDN routing and adaptive bitrate delivery

Red Team This Design

Ready to stress-test this architecture? The Attack companion tears apart every decision in this design — from hardware physics to security holes to what actually happens at 10x scale.

Attack: Design a Video Streaming Platform →