YouTube 影音平台 (Design YouTube)

1. 釐清需求與範圍 (Clarify & Scope ~4 min)

開場後先框邊界，別急著畫 transcoding pipeline（hard 題最常見死因：一上來就秀 ffmpeg 細節卻沒先講端到端 flow）。

2. 功能性與非功能性需求 (FR / NFR 與設計北極星)

• 功能性需求 (FR)

  • 使用者 上傳影片（upload videos）。
  • 使用者 串流觀看影片（stream videos）。
  • （Out of scope：search / comment / recommended videos。）

• 非功能性需求 (NFR)

  • 高可用性，可用性優先於一致性（AP）。
  • 支援 大型影片（單支可達數十 GB）的上傳與串流。
  • 低頻寬下仍低延遲 的串流體驗。
  • 水平擴展：~1M 上傳/day、~100M 觀看/day。

設計北極星（NFR 直接導出後續所有選型的判準）：

3. 容量估算 (Back-of-Envelope ~4 min)

估算目的不是算到精確，而是 驅動 DB / 儲存 / 頻寬決策。回連 02-Distributed-Systems/05-Numbers-to-Know。

寫流量（upload QPS）

~1,000,000 uploads/day ÷ 86,400 s ≈ 11.6 uploads/sec   （平均；實際有 burst）

讀流量（watch QPS）

~100,000,000 watches/day ÷ 86,400 s ≈ 1,157 watches/sec
write:read ≈ 1:100（與上傳對比）→ 讀重於寫

Metadata 儲存

~1M videos/day × 365 ≈ 365M 筆/year
→ 單表年增數億筆 → 必須可水平分割（Cassandra）

影片 bytes 儲存與頻寬（量級感）

單支可達數十 GB；每支還要存「多種 format × 多段 segments」→ 一支膨脹成數份
→ 總量 PB 級 → 只能放 blob storage（S3），不可能進 DB
→ 觀看是 GB 級 bytes × 1,157/sec 的出口頻寬 → 必須 CDN 卸載，否則 origin 頻寬爆

下表 QPS / 筆數皆為 推導值（由「每日次數 ÷ 86,400」「每日筆數 × 365」算出；來源僅給 ~1M 上傳/day、~100M 觀看/day、單支數十 GB 等輸入，未給精確 QPS）。

4. 用到的積木 / Building Blocks Used

架構即目錄：先給導覽圖，再展開。下表每個決策都對映既有 concept note（無 alias 連結）；本表即「本案例練到哪些積木」的單一事實來源（single source of truth）。

5. API 設計 (API Design ~3 min)

關鍵：上傳 API 不收影片本體，只發 presigned URL（理據見第 8.2、10-Design-Patterns/04-Handling-Large-Blobs）。

6. 資料模型與儲存選型 (Data Model & Storage Choice ~5 min)

核心在於 metadata 與 video data 物理分離：結構化的進 DB，GB 級 bytes 進 blob store。

VideoMetadata (NoSQL, e.g. Cassandra)
--------------------------------------------------
video_id        STRING   PK / partition key   ← 均勻分散用
uploader_id     STRING
title           STRING
description     TEXT
duration        INT
status          ENUM     uploading | processing | complete   ← 轉碼/上傳狀態機
upload_id       STRING   S3 multipart UploadId（續傳用）
chunks[]        LIST     每個 part 的 {partNumber, etag, size, done}  ← 續傳進度
manifest_url    STRING   指向 S3 上的 primary manifest（觀看入口）
s3_location     STRING   最終 object / segment 前綴位置
created_at      TIMESTAMP
--------------------------------------------------
~1M 筆/day × 365 ≈ 365M 筆/year → 必須水平分割

S3 (Blob Storage) 上的物件（DB 不存 bytes，只存上面這些指標）
--------------------------------------------------
/{video_id}/raw                       ← 原始上傳檔（multipart 組成）
/{video_id}/{format}/seg_0001.ts ...  ← 多 format × 多 segments
/{video_id}/primary.m3u8              ← primary manifest
/{video_id}/{format}/media.m3u8       ← 各 format 的 media manifest
--------------------------------------------------

儲存選型：

→ 積木：DB 選型理據見 06-Database-Tech/03-DynamoDB、06-Database-Tech/01-Database；水平分割見 05-Database-Advanced/02-Sharding；bytes 走 07-Caching-Storage/02-Blob-Storage。

7. 高階架構 (High-Level Design ~6 min)

把積木串成端到端流程。先看兩條核心 flow，再看 scaled 架構。

(A) 上傳 flow（upload：presigned URL + multipart）

Client
  │  POST /videos/presign_url { VideoMetadata }
  ▼
Video Service (stateless)
  │ 1. 在 metadata table INSERT 一筆（status=uploading）
  │ 2. 用雲端憑證為該物件產生 presigned URL（multipart → 每個 part 一個 URL）
  ▼
回傳 presigned_url(s) ──────────────►  Client
                                        │  PUT part bytes 直傳 S3（繞過 service）
                                        ▼
                                       S3  ──回 ETag──► Client ──回報 {partNumber, etag}──► Video Service
                                        │                                 （更新 metadata chunk 狀態）
   全部 part 完成 → Client 通知 service → CompleteMultipartUpload → 組成最終 object
        │
        ▼  (上傳完成事件)
   Video Processing Service（離線，非同步）  ← 觸發 post-processing DAG

(B) 觀看 flow（watch：ABR）

Client
  │  GET /videos/:videoId
  ▼
Video Service → 回 VideoMetadata（含 S3 上 primary manifest 的 URL）
  │
  ▼
Client 下載 primary manifest（列出各 format 的 media manifest）
  │ 依「目前網速 / 使用者設定」選一個 format
  │ 從 media manifest 取第 1 段 segment URL → 拉 segment（走 CDN edge）
  ▼
邊播第 1 段、邊下載後續段
  │ 偵測網速變差 → 改拉「更高壓縮 / 更低解析度」的 segment（避免卡頓）
  │ 偵測網速變好 → 改拉更高畫質 segment
  ▼
持續串流（client 是主動方：ABR 決策在 client）

(C) Scaled 架構（端到端）

                                  ┌──────────────────────────────────────┐
   觀看 segments / manifest ──────►│              CDN (edge)               │  ← 11-Infrastructure/05-CDN
   （全球就近、低頻寬低延遲）       │  快取 segments + manifest；miss 才回源 S3 │
                                  └───────────────┬──────────────────────┘
                                                  │ (cache miss → origin)
   Client ──────► Load Balancer ──► ┌─────────────────────────────────┐
   (presign / 查 metadata)          │  Video Service (stateless, N 台)  │  ← 加機器即水平擴展
                                    └──────────┬──────────────────────┘
                                               │ 查/寫 metadata（hot 加 cache）
                                               ▼
                                ┌────────────────────────────────────┐
                                │ VideoMetadata  NoSQL (Cassandra)     │
                                │ partition key = video_id（均勻散）    │
                                │ hot video → 加 replica / 前置 cache    │
                                └────────────────────────────────────┘

   Client ──(presigned URL, 直傳/直拉 bytes)──► ┌──────────────┐
                                               │  S3 (Blobs)   │ raw / segments / manifests
                                               └──────┬───────┘
                                                      │ (上傳完成事件)
                                                      ▼
        ┌───────────────────────────────────────────────────────────┐
        │  Video Processing Service                                   │
        │   internal Queue（吸收 burst；queue 深度 → worker autoscale）│ ← 09-Messaging-Coord/02-Queue
        │   DAG orchestrator（如 Temporal）：切段→轉碼→產 manifest    │ ← 09-Messaging-Coord/01-Data-Pipeline
        │   worker nodes（平行處理各 segment）→ 寫回 S3 → status=complete│
        └───────────────────────────────────────────────────────────┘

關鍵 hand-off：控制平面（presign / metadata）走 LB→stateless Video Service→NoSQL；資料平面（GB 級 bytes）完全旁路，走 client↔S3↔CDN；轉碼是離線 pipeline，靠 queue 解耦上傳尖峰、靠 DAG 平行+重試。

8. 深入探討 (Deep Dives ~9 min)

8.1 post-processing 如何運作以支援 ABR（轉碼 DAG）

問題：原始上傳檔無法直接串流；要產出「多 format × 多 segments + manifest」才能在各裝置、各網速播放。
為何是瓶頸：轉碼是 CPU 密集、單支可能跑很久 的工作；若同步做會阻塞上傳、若無編排則無法平行 + 重試。

選擇與理由：採 B。轉碼是典型 long-running task，用 internal queue 解耦上傳尖峰、用 DAG orchestrator 平行處理各 segment 並對失敗步驟重試；queue 深度還能當 worker auto-scaling 訊號。
→ 積木：10-Design-Patterns/03-Long-Running-Tasks、09-Messaging-Coord/01-Data-Pipeline、09-Messaging-Coord/02-Queue

8.2 如何支援可續傳上傳（resumable multipart upload）

問題：單支可達數十 GB，上傳中途斷線是常態。
為何是瓶頸：若「上傳失敗就整支重來」，GB 級檔幾乎永遠傳不完；且 bytes 不能經過我們的 service（否則 service 變成 GB 級流量的瓶頸）。

流程（續傳關鍵在「server 記每個 chunk 狀態」）：

1. server 呼叫 CreateMultipartUpload（這步打 S3）→ 取得 UploadId
2. server 本地為每個 part 產生 presigned URL（不需再打 S3）
3. 每個 part：client PUT 直傳 S3 → 讀回 ETag → POST {uploadId, partNumber, etag} 回 server
   → server（可 ListParts 比對）更新 metadata 中該 chunk = done
4. 全部完成 → client 通知 server → server CompleteMultipartUpload(所有 partNumber+eTag)
   → 組成最終 S3 object → 更新 metadata 的最終位置 + status

續傳怎麼做：client 中途停了，重新取 VideoMetadata → 看哪些 chunk 已 done → 跳過、只補未完成的 part。
→ 積木：10-Design-Patterns/04-Handling-Large-Blobs、07-Caching-Storage/02-Blob-Storage

8.3 如何擴展以支援大量上傳與觀看（scale + CDN）

問題：~100M 觀看/day（每次拉 GB 級）、~1M 上傳/day（每次 GB 級）、metadata 年增數億筆。
為何是瓶頸：真正的壓力是 bytes/sec 出口頻寬 與 metadata 寫入/熱點，而非單純 QPS。

選擇與理由：控制平面靠 stateless + LB 線性擴展，metadata 靠 partition key 均分 + hot key 用 cache/replica，轉碼靠 queue + autoscale 吸收尖峰，觀看頻寬靠 CDN edge 卸載——CDN 是觀看路徑的決定性補強：沒有它，origin（S3）的出口頻寬會被 GB 級觀看流量打爆，遠端使用者也達不到「低頻寬低延遲」的 NFR。
→ 積木：11-Infrastructure/05-CDN、07-Caching-Storage/01-Caching、09-Messaging-Coord/02-Queue

9. 擴展與瓶頸 (Scaling & Bottlenecks ~3 min)

主動找出系統會先在哪裂開並補強（訓練 drive 而非被動回答）。

10. 取捨總表與收尾 (Trade-off Recap & Wrap-up ~1 min)

後續追問演練 (Interviewer Follow-ups — "What if…")

主動回想：白板重建 (Whiteboard from Scratch)

不看上文，照下面提示把整個設計重建一次。每格都該能 30 秒內口述。

• 0. Frame：一句話定位 + 宣告 35 min 配速 + 招牌取捨（bytes 旁路 service）→ __
• 1. Clarify：列 3 個必問（單支多大？AP/CP？範圍含不含 search/comment？）→ __
• 2. FR / NFR：2 個 FR、4 個 NFR、一句話北極星 → __
• 3. 估算：upload QPS / watch QPS / metadata 年增 / 影片總量量級 + 結論（瓶頸是 bytes 不是 QPS）→ __
• 4. Building Blocks：默寫 ≥8 個決策→積木對映 → __
• 5. API：presign_url（為何不直接 upload）+ GET /videos/:id（回 manifest URL）→ __
• 6. 資料模型：VideoMetadata 主要欄位（status/upload_id/chunks/manifest_url）+ S3 物件佈局 + 為何 metadata 與 bytes 分離 → __
• 7. 架構：畫 upload flow（presign+multipart+ETag）/ watch flow（manifest+ABR）/ scaled 圖（LB→stateless service→NoSQL；client↔S3↔CDN；queue+DAG worker）→ __
• 8. Deep Dives：轉碼 DAG（切段→轉碼→產 manifest→complete）、multipart 續傳（chunk 狀態+跳過已完成）、scale+CDN → __
• 9. Scaling：先在哪裂開（觀看頻寬）？CDN / stateless+LB / partition+cache / queue autoscale / DAG 重試 → __
• 10. Recap：一句話招牌取捨 = ？（bytes 永不經 service）→ __

常見陷阱 (Exam Traps for This Problem)

Related Notes

• 02-Distributed-Systems/05-Numbers-to-Know
• 02-Distributed-Systems/03-Scalability
• 05-Database-Advanced/02-Sharding
• 06-Database-Tech/03-DynamoDB
• 06-Database-Tech/01-Database
• 07-Caching-Storage/01-Caching
• 07-Caching-Storage/02-Blob-Storage
• 09-Messaging-Coord/01-Data-Pipeline
• 09-Messaging-Coord/02-Queue
• 10-Design-Patterns/03-Long-Running-Tasks
• 10-Design-Patterns/04-Handling-Large-Blobs
• 10-Design-Patterns/05-Real-time-Updates
• 11-Infrastructure/02-Load-Balancer
• 11-Infrastructure/05-CDN