Design YouTube

Each phase is what the interviewer expects you to do and say. Concrete steps, not topic hints. The diagrams are what you sketch on the board.

1. 1

   Clarify Requirements and Scale

   5 min

   GoalSeparate the three independent paths (upload + transcode, playback via CDN, recommendations) and pin the transcoding DAG decision early. Most candidates blur these together; the interviewer wants to see you carve them up.

   Do & Say

   1. SAY·1SAY: “This is three independent systems sharing infra.” The write path: “upload + transcode, compute-bound and async”. The read path: “playback, bandwidth-bound and CDN-driven”. The recommendation path: “ML-inference-bound and sub-200ms”. Write all three on the board.
   2. SAY·2Pin the scale: “500 hours/min upload = 50 videos/sec”, “1B hours/day watched = 42M concurrent”, “1 Mbps weighted bitrate → 40 Tbps egress”, “800M videos in catalog, 50M peak concurrent viewers”. Write “40 Tbps egress, 50 videos/sec ingest” on the board.
   3. SAY·3Pin the SLOs: “time-to-playable under 30 min for a 10-min video”, “first few segments playable within 60 sec”, “playback startup sub-2s TTFB”, “recommendation feed sub-200ms p99”.
   4. SAY·4Pin the storage decision: “raw uploads to object storage”, “transcoded segments to object storage with CDN in front”, “video metadata in ScyllaDB (not PostgreSQL)” because “we need millions of metadata reads/sec for page loads”. “PostgreSQL stays for users and billing where ACID matters.”
   5. SAY·5Scope in: “upload + transcode pipeline”, “adaptive bitrate playback via CDN”, “view count aggregation”, “basic recommendation architecture”. Out: “monetization/ads”, “content moderation internals”, “live streaming”, “Shorts”. Wait for confirmation.

   Interviewer is grading: You carve up the three paths before drawing anything. You volunteer the transcoding-is-async constraint early. You pick object storage for video data and ScyllaDB for metadata, and can give one-line reasons for both.

2. 2

   API and Data Model

   5 min

   GoalThree endpoints: upload init, playback manifest, view heartbeat. Justify the presigned-URL pattern for upload, the HLS manifest for playback, and ScyllaDB partitioning for metadata.

   Do & Say

   1. WRITE·1Write the upload init: “POST /api/v1/videos {title, description}” returns “{video_id, presigned_upload_url}”. Creator's app PUTs raw file directly to S3 via “multipart upload” (no proxy through our servers). Then “POST /api/v1/videos/{id}/complete” fires “UploadComplete” event to Kafka, which triggers the Temporal workflow.
   2. WRITE·2Write the playback endpoint: “GET /api/v1/videos/{id}/manifest” returns “signed CDN URL to master.m3u8”. The player “fetches master.m3u8”, “picks a variant based on bandwidth”, then “fetches 4-second segments from CDN”. Player “switches variants mid-stream” if bandwidth changes (adaptive bitrate).
   3. WRITE·3Write the view heartbeat: “POST /api/v1/views/heartbeat {video_id, position_sec, session_id}” fires “every 30 seconds” during playback. Goes to Kafka topic “view.heartbeats”. “Flink aggregates in 1-minute tumbling windows”, writes “approximate counts to Valkey”. “Daily batch job reconciles exact counts in ClickHouse.”
   4. SAY·4Justify presigned URL: “Creator uploads 1.5 GB on average”. Proxying through our servers means “75 GB/sec ingest at 50 videos/sec”. Presigned URL means “S3 takes the upload directly, our servers see only the metadata POST”. Standard pattern for any large-file upload.
   5. DRAW·5Sketch the ScyllaDB videos table. Partition key “video_id”. Columns: “channel_id”, “title”, “description”, “status (uploading/processing/playable/removed)”, “visibility”, “view_count”, “like_count”, “manifest_url”, “thumbnail_urls (map<resolution, url>)”, “captions (list<frozen<caption_track>>)”. With captions and full descriptions embedded, “~50 KB per row average”. “800M rows is ~40 TB raw, ~120 TB at RF=3 across a 50-node cluster.”

   Interviewer is grading: You use the presigned-URL pattern for upload (don't proxy 1.5 GB files through your API). You return only a manifest URL for playback and let the CDN serve the segments. You volunteer ScyllaDB over PostgreSQL for video metadata with a throughput reason.

3. 3

   High-Level Design (draw the three paths)

   10 min

   GoalOne diagram with three labeled paths: upload + transcode (Client -> S3 -> Kafka -> Temporal -> GPU fleet -> S3 segments), playback (Client -> CDN -> Origin shield -> S3), recommendation (Client -> Reco API -> two-stage retrieval+ranking).

   Draw on the board
   Do & Say

   1. DRAW·1Draw the upload + transcode path first, it's the most complex. “Creator uploads to S3 via presigned URL.” Then “UploadComplete fires to Kafka.” Then “Temporal orchestrates the transcoding DAG.” Key insight: “split the video into 4-second segments first, not transcode the whole thing.”
   2. SAY·2Defend the segment-based DAG: “10-min video → 150 segments”, “each encodes to 12 variants (5 H.264, 4 VP9, 3 AV1)”, “1,800 independent tasks per video”, “parallelized across 5,000 T4 GPUs on spot”, “~2s per task on a T4”, “wall-clock 3-5 min instead of 30+ sequential.”
   3. SAY·3Defend the variant set: “H.264 at every resolution for universal decoder support”, “VP9 at 720p+ for 30-40% bitrate savings (hardware decoders since 2015)”, “AV1 at 720p+ for another 30-50%, player falls back if not supported”, “360p/480p get H.264 only since low-bitrate savings are negligible.”
   4. SAY·4Pivot to playback. “Viewer requests manifest.” “Streaming Service returns signed master.m3u8 listing all variants.” “Player fetches from CDN, picks initial variant from bandwidth probe, fetches 4-second segments.” “If bandwidth drops, switch variants on next segment boundary.” Standard HLS adaptive bitrate.
   5. SAY·5Defend multi-CDN: “Akamai, Cloudflare, Fastly run in parallel”. “DNS GSLB steers viewers to nearest healthy CDN.” “Akamai EU down → traffic shifts to Cloudflare EU in ~10s.” “95%+ cache hit on popular content.” “Origin shield with request coalescing absorbs viral misses: 1000 edges asking for the same segment fan into one S3 fetch.”
   6. SAY·6Pivot to recommendation. “Two-stage.” Retrieval: “narrow 800M videos to ~5000 candidates using two-tower embeddings (user embedding + video embedding, ANN lookup)”. Ranker: “score those 5000 with a gradient-boosted tree or DNN using watch-time-weighted features, returns top 50”. “Feature store is Valkey for sub-ms lookups.” “Total p99 ~150ms.”
   7. SAY·7Pivot to view counts: “heartbeat every 30s into Kafka view.heartbeats, partitioned by video_id”. “Flink does 1-min tumbling aggregation, writes approximate per-video counts to Valkey for the UI.” “Daily ClickHouse batch reconciles exact.” “View-count accuracy is not tier-1 so a 1-min lag is fine.”

   Interviewer is grading: You separate the four paths visibly (upload + transcode, playback, recommendation, view counts). You volunteer the 4-second-segment DAG before being asked. You name Temporal (or equivalent workflow engine) for orchestration, not 'just retry with Kafka'. You volunteer origin shield + request coalescing for viral playback.

4. 4

   Deep Dive: Transcoding DAG, CDN Strategy, View Counts

   15 min

   GoalThree sub-dives. First, why the segment-based DAG beats two simpler approaches. Second, multi-CDN with traffic steering and cache warming. Third, view-count counting strategy (approximate real-time + exact batch).

   Draw on the board
   Do & Say

   1. SAY·1Pivot to transcoding. Sync monolithic: “one worker produces all variants sequentially”, “30-min 4K with 15 variants takes 2.5 to 7.5 hours”, “crash at variant 14 → restart”. “At 500 hours/min uploaded, queue grows faster than we drain.” Dead.
   2. WATCH·2Knock out parallel-per-variant: “Better latency, but each of the 15 workers reads the entire raw file from S3.” “5 GB raw × 15 reads = 75 GB S3 egress per video.” “At 3000 videos/min that's 225 TB/min of redundant reads.” Wasteful.
   3. SAY·3Defend segment-based DAG: “Split into 4-second segments”, “each fans out to 12 encoding tasks”, “150 × 12 = 1800 tiny tasks”, “parallelism on 5000 T4 spot GPUs”, “fine-grained retry”, “progressive availability so first 10 segments play while later ones encode.”
   4. SAY·4Defend Temporal: “1800 tasks per video × 50 videos/sec = 90K concurrent tasks”. Needs: “workflow state (done, retrying, dead)”, “backoff retries”, “ops visibility”. All native in Temporal. “Airflow and Step Functions work, but Temporal's worker model fits long-running encoding better.”
   5. SAY·5Cover GPU sizing: “50 videos/sec × 1 GPU-hour each = 180K GPU-seconds/sec”, “5000 T4s at ~36 NVENC sessions each = 180K concurrent sessions, balanced”, “spot at $0.16/hr = $7M/year”. “4-second segments survive reclamation since Temporal retries elsewhere.”
   6. SAY·6Pivot to CDN strategy. “Multi-CDN is mandatory for video at this scale.” “Single-CDN means a regional outage is a global incident.” “Akamai, Cloudflare, Fastly run in parallel.” “DNS-based GSLB steers each viewer to nearest healthy CDN, weighted by per-CDN metrics (RTT, error rate, cost).”
   7. SAY·7Defend origin shield + coalescing: “Viral video hits 10M viewers in 60s.” “Edges miss, haven't cached yet.” “Without coalescing, every edge slams S3.” “Origin shield sees 1000 edges asking for the same segment, fires one S3 fetch, broadcasts.” “1000x origin load reduction.”
   8. SAY·8Defend proactive warming: “Flink tracks view-velocity per video.” “When trending (>100 views/sec or >50% acceleration), push first 2 min of segments to edge PoPs.” “First 2 min carries ~60% of views, high-leverage warm.” “Segments at edge by the time 10M viewers arrive.”
   9. SAY·9Pivot to view counts: “heartbeats fire every 30 seconds during playback”, “1B hours/day × 2 heartbeats/min = 120B heartbeats/day = 1.39M events/sec”, “Kafka partitioned by video_id with 200 partitions across 50 brokers”, “Flink does 1-min tumbling aggregation and writes per-video counts to Valkey.”
   10. SAY·10Defend approximate-then-exact: “UI shows approximate from Valkey within 1 min”, “daily ClickHouse batch scans Kafka and reconciles to exact, fixing Flink drift”, “approximate is fine for UI, no user notices 0.1% drift”, “exact is needed for creator payouts which run on daily batch.”
   11. SAY·11Cover hot-metadata failure: “Viral video's ScyllaDB row gets millions of reads/sec on one vnode → hot partition.” Mitigation: “Valkey with 1-hour TTL absorbs reads”, “ScyllaDB sees one read per hour per Valkey shard”. Super Bowl scale: “Flink writes the live counter to Valkey directly and bypasses ScyllaDB on that field.”

   Interviewer is grading: You volunteer the three transcoding architectures and kill the first two with one-line reasons. You name Temporal (or equivalent) as the workflow engine, not 'just Kafka with retries'. You bring up origin shield + request coalescing for viral content unprompted. You separate approximate (Flink + Valkey) from exact (daily ClickHouse) for view counts and can defend each.

5. 5

   Trade-offs, Risks, and Wrap-up

   5 min

   GoalName three deliberate trade-offs (approximate view counts, spot GPU instances, ScyllaDB tunable consistency), give a failure plan for a CDN outage, close in one breath.

   Do & Say

   1. SAY·1Approximate view-count trade-off: “UI from Valkey via Flink with 1-min lag”, “exact via daily ClickHouse batch”. “We accept a 13:00 count off by 0.1% until next-day reconcile.” “No user notices, payouts run on exact.” “Real-time exact would need cross-region sync, too expensive.”
   2. SAY·2Spot GPU trade-off: “5000 T4s on spot = $7M/year vs $25M on-demand”. “We accept AWS reclaiming ~30% of the fleet during capacity events.” “Temporal retries interrupted segments on healthy instances.” “Worst case: 5-min transcode takes 15 min.” “Creator SLO is 30 min, still inside it.” Savings are real money.
   3. SAY·3ScyllaDB consistency trade-off: “metadata reads use LOCAL_ONE (any replica)”, “view count writes from Flink use LOCAL_QUORUM (2 of 3 replicas)”. “We accept slightly stale view counts on read in exchange for sub-ms p99 reads.” “Source of truth for exact counts is ClickHouse, so any ScyllaDB drift is reconciled daily.”
   4. SAY·4CDN outage plan: “Akamai EU down 15 min.” “GSLB catches it in 10s, shifts EU to Cloudflare EU.” “Cloudflare cache cold, hit rate drops to ~60% for 1-2 min.” “Origin shield absorbs misses.” “Cache warms organically by 5 min.” “Users see 10-30s stall at failover then normal playback.”
   5. SAY·5Close: “upload via Temporal DAG of 1800 tasks on 5000 spot GPUs”, “playback via multi-CDN with origin shield and proactive warming”, “recommendation as two-stage retrieval-then-rank with Valkey at sub-200ms p99”. “ScyllaDB metadata, S3 video, ClickHouse exact counts.” Risk: “viral CDN miss cascade, mitigated by coalescing and warming.”

   Interviewer is grading: You name trade-offs as 'we accept X because Y'. You volunteer the CDN failover plan (DNS GSLB + cache warming) without being asked. The summary mentions all three paths plus the load-bearing CDN risk in one breath.

Questions an interviewer is likely to ask after your walkthrough. Rehearse the short answer.

1. Why the segment-based DAG instead of just parallelizing per variant?
2. Why Temporal and not just Kafka with consumer retries?
3. How does a viral video not melt the CDN?
4. Why approximate view counts in the UI?
5. What if a CDN goes down regionally?
6. How can you justify spot GPUs given the reclamation risk?
7. Why ScyllaDB for video metadata and not PostgreSQL?
8. What about hot metadata when one video goes super viral?