Day 22 我們設計了 Chat System。今天來挑戰另一個經典 System Design：
Design YouTube（設計大型影音平台）
今天仍然遵守同一個規則：
每一個新名詞都先解釋「完整英文 → 中文意思 → 是什麼 → 為什麼需要 →
簡單例子 → System Design
用法」。遇到縮寫時，也會把每一個字拆開解釋。
Requirement（需求）：System 必須完成或滿足的事情。
Functional Requirements（功能性需求）：System 要提供哪些功能。
1. User 可以 Upload Video
2. User 可以 Watch Video
3. 支援不同 Video Quality
4. 顯示 Video Metadata
5. 產生 Thumbnail
Non-Functional Requirements（非功能性需求）：System 應具備什麼品質。
High Availability
Low Playback Latency
Durable Storage
Scalability
Global Delivery
Reliable Upload
今天主要設計 VOD，不深入 Live
Streaming、Comments、Likes、Recommendation 與 Ads。
VOD = Video on Demand
Video → 影片
on Demand → 按照 User 的需求取得
中文：
隨選視訊
意思是 User 想看的時候才選擇並播放已經存在的 Video。
例如：
User clicks a YouTube video
↓
System delivers that video
和 Live Streaming 不同：
VOD → Video 通常已經存在並處理完成
Live Streaming → Video 一邊產生、一邊傳給 Viewer
Upload（上傳）：
把 Data 從 Client 傳到 Server / Cloud Storage。
Creator Laptop
↓
5 GB Video
↓
Internet
↓
Video Platform
大型 Video 最大的問題之一是：
Upload 到 95%
↓
Network disconnected
如果重新從 0% 開始，User Experience 很差。
Chunk（資料塊 / 分塊）：
把大型 Data 拆成比較小的 Pieces。
例如：
5 GB Video
↓
Chunk 1
Chunk 2
Chunk 3
...
假設每個 Chunk 是 10 MB，某個 Chunk 失敗時，不一定需要重傳完整 5 GB。
Chunked Upload（分塊上傳）：
把大型 File 分成多個 Chunks，再分批 Upload。
Video
↓
Chunk 1 → Upload
Chunk 2 → Upload
Chunk 3 → Upload
好處：
Failure Recovery
Progress Tracking
Large File Handling
Resumable Upload（可續傳上傳）
Resume → 繼續
Resumable → 可以繼續的
意思：
Upload 中斷後，可以從之前成功的位置繼續，而不是全部重來。
Chunks 1–90 succeeded
Chunk 91 failed
↓
Reconnect
↓
Continue from Chunk 91
Upload Session（上傳工作階段）：
代表一次完整 Upload 過程的識別與狀態。
upload_id = U123
completed_chunks:
1, 2, 3, 4, 5
Reconnect 後 Client 可以問：
Upload U123 已經成功到哪裡？
Checksum（校驗值 / 檢查碼）：
根據 Data 計算一個值，用來協助檢查傳輸前後的 Data 是否一致。
Original Chunk
↓
Checksum = ABC123
Uploaded Chunk
↓
Checksum = ABC123
相同代表 Data 比較可能沒有在傳輸中損壞。
Checksum 用於檢查 Integrity，不等於 Encryption。
Integrity（完整性）：
Data 在傳輸或保存後仍維持預期內容，沒有被意外修改或損壞。
例如：
Client sends correct Chunk
↓
Network / Storage corruption
↓
Stored Chunk differs
就是 Data Integrity Problem。
Binary = 二進位
Binary Data（二進位資料）：
以 Bytes 表示、不是單純可直接閱讀 Text 的 Data。
例如：
Image
Video
Audio
PDF
Video 通常是大型 Binary Data。
Object Storage（物件儲存）：
把 File / Data 當成 Object 保存的 Storage System，適合大量
Images、Videos、Documents 等大型 Files。
可以想成：
Object Key
+
Data
+
Metadata
例如：
videos/original/U123.mp4
Video Binary 通常放 Object Storage，而不是全部塞進主要 Relational
Database。
這裡的 Object（物件）：
一份被 Object Storage 獨立保存與識別的 Data。
例如：
Original Video
Thumbnail
Subtitle
Processed Video Segment
注意：這裡的 Object 和 Java OOP 的 Object 是不同 Context。
Metadata（中繼資料 / 描述資料的資料）：
描述 Video 的資訊，而不是 Video Binary 本身。
例如：
video_id
title
description
creator_id
duration
created_at
status
thumbnail_url
因此常見：
Object Storage
→ Actual Video Files
Database
→ Video Metadata
常看到：
.mp4
.mov
.webm
這牽涉 Container Format（容器格式）：
把 Video、Audio、Subtitle、Metadata 等不同 Data Streams 包裝在同一個
File 裡的格式。
MP4 Container
├── Video Track
├── Audio Track
├── Subtitle Track
└── Metadata
Container 可以想成「箱子」。
Codec 常理解為 Coder / Decoder，也就是編碼與解碼相關的技術。
中文：
編解碼器
作用：
定義 Video / Audio 如何被壓縮、編碼，以及之後如何解碼播放。
常見 Video Codec：
H.264
H.265 / HEVC
VP9
AV1
先記：
MP4 → Container
H.264 → Codec
兩者不是同一件事。
Encoding（編碼）：
把原始 Data 轉成指定 Representation / Format。
Raw Video
↓
Encoder
↓
Encoded Video
Decoding（解碼）：
把已編碼 Data 解讀成可以播放 / 使用的形式。
Encoded Video
↓
Decoder
↓
Frames on screen
Compression（壓縮）：
降低 Data Size。
Video 如果完全不壓縮會非常大，因此 Codec 會利用畫面中的重複資訊降低
Size。
Lossy Compression（有損壓縮）：
Lossy → 會失去部分資料的
意思：
為了大幅降低 File Size，允許捨棄部分較不重要的資訊。
Trade-off：
Smaller File
↔
Possible Quality Loss
Resolution（解析度）：
Video Frame 的 Pixel Dimensions。
例如：
1920 × 1080
1280 × 720
854 × 480
常寫：
1080p
720p
480p
Pixel = Picture Element
Picture → 圖片
Element → 元素
中文：
像素
Pixel 是 Digital Image 中很小的畫面單位。
1080p 裡的 p 代表 Progressive Scan（逐行掃描）。System Design
不需要深入 Display Technology，只要知道 1080p、720p、480p 常被當成不同
Video Quality Levels。
Bitrate = Bit Rate
Bit → Binary Digit，位元
Rate → 速率
中文：
位元率
意思：
每秒用多少 Bits 表示 / 傳輸 Video Data。
例如：
5 Mbps
Mbps = Megabits per second
Mega → 百萬等級
bits → 位元
per second → 每秒
中文：
每秒 Megabits
注意：
Mb → Megabit
MB → Megabyte
1 Byte = 8 bits
所以粗略：
8 Mbps ≈ 1 MB/s
Resolution
→ 畫面有多少 Pixels
Bitrate
→ 每秒使用多少 Bits
同樣是 1080p，可以有不同 Bitrate。
Bitrate 太低可能造成畫質下降；Bitrate 越高通常需要更多 Bandwidth 和
Storage。
Bandwidth（頻寬）：
Network 在一定時間內可以傳輸多少 Data 的 Capacity。
道路類比：
Latency
→ 車從 Boston 到 New York 要多久
Bandwidth
→ 高速公路同時可以容納多少車流
Video Streaming 非常消耗 Bandwidth。
Creator Upload 一支 4K Video，但 Viewer 可能使用：
Fast Wi-Fi
Slow Mobile Network
Phone
Laptop
4K TV
所以需要 Transcoding（轉碼）：
把一個 Video 轉換成不同 Encoding、Resolution、Bitrate 或 Format
的版本。
Original 4K
↓
Transcoding
├── 2160p
├── 1080p
├── 720p
├── 480p
└── 360p
Rendition（轉製版本 / 不同品質版本）：
同一支 Video 經處理後產生的某一個播放版本。
例如：
1080p @ 5 Mbps
720p @ 2.5 Mbps
480p @ 1 Mbps
每一個都是不同 Rendition。
Transcoding 可能需要很久，所以不適合讓普通 Upload Request 一直等待。
Synchronous（同步式）：
Caller 必須等待 Operation 完成。
Request
↓
Work
↓
Wait
↓
Response
Asynchronous（非同步式）：
先把工作交出去，不需要讓原 Request 等全部工作完成。
Upload finished
↓
Create Processing Job
↓
Return
Background:
Transcode
Generate Thumbnail
Package
Background Job（背景工作）：
不需要 User Request 一直等待，而是在 Background 執行的工作。
例如：
Transcoding
Thumbnail Generation
Video Analysis
Message Queue（訊息佇列）：
Message → 訊息
Queue → 排隊隊伍 / 佇列
在 Video Platform：
把等待處理的 Video Jobs 排隊，讓 Workers 按照 System Capacity 消化。
Upload Service
↓
TRANSCODE_VIDEO U123
↓
Message Queue
↓
Worker
Worker（工作節點 / 工作程序）：
從 Queue 取得 Job 並真正執行工作的 Process / Server。
Worker #1 → Video A
Worker #2 → Video B
Worker #3 → Video C
Pipeline（處理管線 / 流程鏈）：
Data 依序經過多個 Processing Steps。
Upload
↓
Validation
↓
Store Original
↓
Transcode
↓
Generate Thumbnail
↓
Package
↓
Publish
這就是 Video Processing Pipeline（影片處理管線）。
Validation（驗證 / 檢查）：
確認 Input 是否符合 System 規則。
例如：
File type allowed?
File size allowed?
Upload complete?
File corrupted?
不要和 Authentication 混淆：
Authentication → 你是誰？
Validation → 你給我的 Data 合不合理？
Thumbnail（縮圖 / 預覽小圖）：
代表 Video 的小型 Preview Image。
System 可以從 Video 的某個 Frame 產生 Thumbnail。
Frame（影格 / 畫格）：
Video 中某一個時間點的單張畫面。
FPS = Frames Per Second
Frames → 影格
Per Second → 每秒
中文：
每秒影格數
例如：
30 FPS
→ 每秒約 30 Frames
Streaming（串流）：
不需要先完整 Download 整支 Video，就可以一邊接收 Data、一邊播放。
Receive first portion
↓
Start watching
↓
Continue receiving later portions
這就是大型 Video Platform 的核心能力。
Buffer（緩衝區）：
暫時保存一小部分 Data，讓 Consumer 可以比較平穩地處理。
Network
↓
Buffer
↓
Video Player
例如 Player 先準備 10 秒 Video。Network 短暫變慢時，仍可先播放 Buffer
裡的內容。
Buffering（緩衝中）：
Player 正等待更多 Video Data 進入 Buffer。
Rebuffering（重新緩衝）：
Video 已經開始播放後，因 Buffer 不足而再次停下來等待 Data。
Play
↓
Buffer empty
↓
Spinner
↓
Download more
↓
Continue
Segment（片段）：
Streaming 時，把 Video Timeline 切成較小的可傳輸 / 播放單位。
例如：
0–4 sec
4–8 sec
8–12 sec
12–16 sec
Upload Chunk
→ 為了大型 File 分塊上傳
Streaming Segment
→ 為了把 Video Timeline 分段播放
Manifest File（清單檔 / 描述檔）：
告訴 Video Player 有哪些 Renditions、Segments，以及去哪裡取得它們。
1080p
→ segment1
→ segment2
720p
→ segment1
→ segment2
480p
→ segment1
→ segment2
Player 先讀 Manifest，再選適合的 Video Segment。
ABR = Adaptive Bitrate
Adaptive → 可以根據情況調整的
Bitrate → 位元率
完整概念：
Adaptive Bitrate Streaming（自適應位元率串流）
Player 根據 Network / Buffer 狀況，動態選擇不同 Bitrate 的 Rendition。
Fast Wi-Fi → 1080p
Network slower → 720p
Very slow → 480p
目標是在：
Video Quality
↔
Buffering
之間取得平衡。
HLS = HTTP Live Streaming
先拆 HTTP：
HTTP = Hypertext Transfer Protocol
Hypertext → 超文字
Transfer → 傳輸
Protocol → 協定
HLS：
HTTP → 超文字傳輸協定
Live → 即時 / 持續傳輸
Streaming → 串流
中文可理解為：
透過 HTTP 傳送影音串流的一種技術
核心概念：
Video
↓
Different Renditions
↓
Small Segments
↓
Playlist
↓
HTTP
↓
Player
雖然名字有 Live，HLS 也可以用於 VOD。
在 HLS Context：
Playlist（播放清單 / 串流清單）：
描述有哪些 Media Segments / Renditions 可以播放。
常見 Extension：
.m3u8
初學者不需要背 Syntax，只要知道：
Playlist
→ 告訴 Player 下一段 Video 在哪裡
DASH = Dynamic Adaptive Streaming over HTTP
逐字：
Dynamic → 動態的
Adaptive → 自適應的
Streaming → 串流
over HTTP → 透過 HTTP
中文：
透過 HTTP 進行動態自適應串流
DASH 和 HLS 都能支援：
Segments
Multiple Renditions
Adaptive Bitrate
HTTP Delivery
MPEG = Moving Picture Experts Group
Moving Picture → 動態影像
Experts Group → 專家組
所以常看到：
MPEG-DASH
DASH 常使用：
MPD = Media Presentation Description
Media → 媒體
Presentation → 呈現
Description → 描述
中文：
媒體播放描述檔
作用類似 Manifest：告訴 Player 有哪些 Renditions、Segments 與位置。
Packaging（封裝 / 串流封裝）：
把 Transcoded Video 整理成 Streaming Protocol 可以使用的 Segments 與
Manifest / Playlist。
1080p
720p
480p
↓
Packaging
↓
Segments
+
HLS Playlist / DASH Manifest
Video Metadata 可以有：
UPLOADING
PROCESSING
READY
FAILED
UPLOADING → Creator 還在上傳
PROCESSING → Transcoding / Packaging 中
READY → 可以播放
FAILED → Processing 無法完成
Event（事件）：
表示「某件事情已經發生」的訊息。
例如：
VIDEO_UPLOAD_COMPLETED
VIDEO_TRANSCODING_COMPLETED
VIDEO_READY
Producer（生產者）：
產生並送出 Message / Event 的 Component。
例如 Upload Service 發：
VIDEO_UPLOAD_COMPLETED
Consumer（消費者）：
接收 Message / Event 並執行工作。
例如 Transcoding Worker 收到 Event 後開始處理 Video。
Retry（重試）：
Operation 失敗後再嘗試。
Transient Failure（暫時性故障）：
Transient → 暫時的
例如：
Temporary Network Error
Storage Timeout
Retry 有機會成功。
Permanent Failure（非暫時性故障）：
例如：
Corrupted Video
Unsupported Format
Retry 100 次通常仍不會成功。
DLQ = Dead Letter Queue
Dead Letter → 無法正常投遞 / 處理的訊息
Queue → 佇列
中文：
死信佇列
多次 Retry 仍失敗：
Job
↓
Retry
↓
Retry
↓
Still Failed
↓
DLQ
讓正常 Queue 不會一直被壞 Job 卡住，也方便 Engineer 調查。
Idempotency（冪等性）：
同一個 Logical Operation 重複執行時，不應產生不必要的重複結果。
例如：
TRANSCODE video_id=123
因 Retry 執行兩次，System 不應建立互相衝突的兩套 Final Records。
CDN = Content Delivery Network
Content → 內容
Delivery → 傳遞
Network → 網路
中文：
內容傳遞網路
作用：
把 Video Segments Cache 在靠近 Users 的 Edge Servers，降低 Network
Distance 與 Origin Load。
Origin（來源站 / 原始內容來源）：
CDN 沒有 Cache 時，真正取得 Content 的上游來源。
例如：
Object Storage
可以是 Video Origin。
Edge Server（邊緣伺服器）：
部署在更靠近 User 的 Network Location，用來快速提供 Content 的
Server。
Taiwan Viewer
↓
Nearby CDN Edge
而不是每次都跨洲到 US Origin。
Cache Hit（快取命中）：
Edge 已經有 User 要的 Segment。
Viewer → Edge → Return directly
Cache Miss（快取未命中）：
Edge 沒有，需要向 Origin 取得。
Viewer
↓
Edge
↓ MISS
Origin
↓
Edge caches content
↓
Viewer
假設：
10M Viewers
5 Mbps per Viewer
如果全部直接打 Origin：
Huge Bandwidth
Huge Origin Load
Higher global latency
CDN：
Origin
↓
Distributed Edge Caches
↓
Millions of Viewers
熱門 Video 可以在靠近 User 的地方重複提供。
Ingress（流入流量）：
Data 從外部進入 System。
Creator → Upload → Cloud
Egress（流出流量）：
Data 從 System 向外傳出。
Cloud / CDN → Viewer
簡單記：
Ingress → In → 進來
Egress → Exit → 出去
Video Egress 很大，因此 Network Cost 是重要 Trade-off。
Viewer
↓
Video Metadata API
↓
Metadata DB
↓
Manifest URL
↓
CDN
↓
Player chooses Rendition
↓
Request Segments
↓
Buffer
↓
Playback
Player 會根據：
Network Condition
Buffer Level
Device Capability
選擇適合的 Rendition。
Capability（能力 / 可支援能力）
Device Capability（裝置能力）：
Device 能支援哪些 Codec、Resolution、Format 或 Processing Load。
即使 Network 很快，舊 Device 也不一定適合播放最高規格 Video。
Playback Startup Time（播放啟動時間）：
User 按 Play 到 Video 真正開始播放所花的時間。
相關指標：
Time to First Frame
Time → 時間
First Frame → 第一個影格
意思：
從播放流程開始，到 User 真正看到第一個 Video Frame 的時間。
Rebuffering Ratio（重新緩衝比例）：
Playback Session 中有多少比例的時間花在 Rebuffering。
例如：
100 seconds session
5 seconds rebuffering
≈ 5%
通常越低越好。
QoE = Quality of Experience
Quality → 品質
Experience → 體驗
中文：
體驗品質
關心 User 實際感覺播放好不好。
例如：
Startup Time
Rebuffering
Video Quality
Playback Errors
Quality Switching
QoS = Quality of Service
Quality → 品質
Service → 服務
中文：
服務品質
簡化區分：
QoS → Network / System Service Quality
QoE → User Perceived Experience
Availability（可用性）：
User 需要服務時，System 能正常提供服務的程度。
如果 Metadata API Down，User 可能連 Video Page 都打不開。
Durability（持久性）：
已成功保存的重要 Data，不應因單一 Failure 輕易消失。
Video Upload 成功後，不應因一台 Storage Machine Failure 就永久消失。
Replication（複寫 / 複製）：
把 Data 保存多份 Copies。
Video Object
├── Copy A
├── Copy B
└── Copy C
可能提高：
Durability
Availability
Failure Recovery
但增加 Storage Cost。
Redundancy（冗餘）：
額外保留 Components / Data Copies，避免單一 Failure 讓服務完全失效。
例如：
Multiple API Servers
Multiple Workers
Multiple Storage Copies
SPOF = Single Point of Failure
Single → 單一
Point → 點
Failure → 故障
中文：
單點故障
意思：
某個 Component 一旦 Failure，整個重要功能就停止。
只有一台 Transcoding Worker，它掛掉後全部 Processing 停止，就是 SPOF。
Horizontal Scaling（水平擴展）：
增加更多 Machines / Workers 共同處理 Workload。
1 Worker
↓
10 Workers
↓
100 Workers
Backlog（待處理積壓）：
Queue 裡已經進來、但還沒有處理完成的 Jobs。
如果：
Incoming Rate > Processing Rate
Backlog 會持續增加。
Throughput（吞吐量）：
System 在一定時間內可以完成多少 Work。
例如：
100 Videos/minute
不要和 Latency 混淆：
Latency → 一個 Job 多久完成
Throughput → 一段時間完成多少 Jobs
Observability（可觀測性）：
利用 Metrics、Logs、Traces 等 Signals 理解 System 內部狀態。
Upload Success Rate
Upload Failure Rate
Upload Latency
Chunk Retry Rate
Queue Backlog
Transcoding Success Rate
Processing Latency
Worker Utilization
DLQ Size
Playback Startup Time
Time to First Frame
Rebuffering Ratio
Playback Error Rate
Average Bitrate
CDN Cache Hit Rate
Authentication（身分驗證）：
確認「你是誰」。
Are you Alvin?
Authorization（授權）：
確認「你可以做什麼」。
Can Alvin delete Video V123?
即使 User 已登入，也不能刪除別人的 Video。
Access Control（存取控制）：
控制誰可以對哪些 Resources 執行哪些 Actions。
Public Video → everyone can view
Private Video → only allowed users
Signed URL（簽名網址）：
帶有 Cryptographic Verification 與限制條件的暫時性 URL，用來授權
Client 在特定時間內存取 Resource。
例如：
video_url
+
expires_at
+
signature
過期後 URL 失效。
Signature（簽章 / 驗證值）：
使用 Cryptographic Method 產生的驗證資訊，讓 Server / Storage 確認 URL
是否合法且未被竄改。
Expiration（過期）：
Credential / URL 在指定時間後失效。
例如：
Signed URL valid for 10 minutes
假設：
10M Video Uploads/day
Average Original Video = 500 MB
每天 Original Data：
10M × 500 MB
≈ 5 PB/day
這只是 Interview Assumption，不代表真實 YouTube 數字。
PB = Petabyte
Peta → 很大的 Data Unit Prefix
Byte → 位元組
粗略估算：
1 PB ≈ 1,000 TB
1 TB ≈ 1,000 GB
Storage Amplification（儲存放大）：
一份 Original Data 經 Processing 後產生多份額外 Data，使總 Storage
大於 Original。
Original
+
1080p
+
720p
+
480p
+
360p
+
Thumbnails
+
Segments
再加 Replication，實際 Physical Storage 會更大。
假設：
1M Concurrent Viewers
Average Bitrate = 3 Mbps
總 Delivery Rate：
1M × 3 Mbps
= 3,000,000 Mbps
= 3 Tbps
Tbps = Terabits per second
Tera → 兆等級 Prefix
bits → 位元
per second → 每秒
中文：
每秒 Terabits
這說明 Video Delivery 會產生極大的 Network Traffic，因此 CDN 很重要。
Compute（運算資源 / 計算能力）：
CPU、GPU 等執行 Processing Work 的 Computing Resources。
Transcoding 通常很 Consume Compute。
CPU = Central Processing Unit
Central → 中央
Processing → 處理
Unit → 單元
中文：
中央處理器
負責大量 General-Purpose Computation。
GPU = Graphics Processing Unit
Graphics → 圖形
Processing → 處理
Unit → 單元
中文：
圖形處理器
GPU 擅長大量 Parallel Computation。某些 Video Processing 可以利用 GPU
或其他專用 Hardware。
Hardware Acceleration（硬體加速）：
使用專門 Hardware 加速某類工作，而不是完全依賴一般 Software / CPU
Processing。
例如某些 Video Encoding / Transcoding Workloads 可以透過專用 Hardware
提高 Throughput。
High-Level Architecture（高階架構）：
先看主要 Components 與 Data Flow，不深入每個 Implementation Detail。
Creator
│
↓
API / Upload Service ───────→ Metadata DB
│
↓
Upload Session
│
↓
Chunked / Resumable Upload
│
↓
Object Storage
(Original Video)
│
↓
VIDEO_UPLOAD_COMPLETED
│
↓
Message Queue
│
↓
Processing Workers
│
├── Transcoding
├── Thumbnail
└── Packaging
│
↓
Object Storage
(Processed Renditions / Segments)
│
↓
CDN
│
↓
Viewer
1. Creator authenticates
2. Client requests Upload Session
3. Server creates video_id / upload_id
4. Client uploads Video in Chunks
5. Object Storage saves Original Video
6. Validate Upload completion
7. Publish VIDEO_UPLOAD_COMPLETED
8. Worker consumes Job
9. Transcode multiple Renditions
10. Generate Thumbnail
11. Package Streaming Segments
12. Store processed outputs
13. Update status = READY
1. Viewer opens Video Page
2. API returns Metadata
3. Player gets Manifest / Playlist
4. Player estimates Network / Buffer
5. Select Rendition
6. Request Segment from CDN
7. Cache Hit → return immediately
8. Cache Miss → fetch from Origin
9. Put Segment into Buffer
10. Start Playback
11. Continue requesting Segments
12. ABR changes Bitrate when needed
Problem：
5 GB Video
95% uploaded
Network disconnected
Solution：
Chunked Upload
+
Upload Session
+
Resumable Upload
+
Checksum
只補 Missing / Failed Chunks。
Worker starts Job
↓
Worker crashes
可以：
Queue
↓
Retry
↓
Another Worker
同時搭配 Idempotency，避免 Duplicate Processing 造成錯誤結果。
Celebrity uploads Video
↓
10M Users watch
如果：
Everyone → Origin
Origin 可能成為 Bottleneck。
Solution：
CDN
↓
Edge Cache
↓
Distributed Delivery
1080p @ 5 Mbps
↓
Network drops
↓
Buffer decreases
Solution：
ABR
↓
Switch to 720p / 480p
↓
Reduce Rebuffering
Trade-off：
Lower Quality
but
Smoother Playback
不要一開始就說：
Use CDN + Kafka + Redis + NoSQL.
先問：
1. VOD or Live?
2. Need Upload?
3. Need Multiple Qualities?
4. Global Playback?
5. Private Videos?
6. Expected DAU?
7. Upload Volume?
8. Concurrent Viewers?
9. Average Video Size?
10. Need Comments / Likes / Recommendation?
可以回答：
Video files are large binary objects. Storing large video binaries
directly in the main relational database can increase database I/O,
backup, replication, and serving costs. I would usually store video
binaries in object storage and keep searchable metadata such as title,
creator, duration, and processing status in a database.
Different viewers have different network bandwidth, devices, and
display capabilities. Transcoding creates multiple renditions with
different resolutions, bitrates, or codecs so the player can select an
appropriate version.
Transcoding is compute-intensive and may take much longer than a
normal API request. The upload service can persist the original video,
enqueue a processing job, return quickly, and let background workers
process it asynchronously.
Video delivery consumes huge bandwidth. If every viewer fetches every
segment directly from the origin, the origin can become a bottleneck.
A CDN caches popular segments at edge locations closer to users,
reducing network distance and origin load.
不要背：
YouTube = NoSQL
先分析：
Access Pattern
Data Model
Read / Write Volume
Consistency Requirement
Query Pattern
Scale
Operational Complexity
例如 Metadata 和 Video Binary 本身就是兩種非常不同的 Data。
Requirements
□ Functional Requirement
□ Non-Functional Requirement
□ VOD
□ Live Streaming
Upload
□ Chunk
□ Chunked Upload
□ Resumable Upload
□ Upload Session
□ Checksum
□ Integrity
Storage
□ Binary Data
□ Object Storage
□ Object
□ Metadata
□ Container Format
□ Replication
□ Durability
Video Basics
□ Codec
□ Encoding
□ Decoding
□ Compression
□ Lossy Compression
□ Resolution
□ Pixel
□ Bitrate
□ Mbps
□ Bandwidth
□ FPS
Processing
□ Transcoding
□ Rendition
□ Synchronous
□ Asynchronous
□ Background Job
□ Message Queue
□ Worker
□ Pipeline
□ Validation
□ Thumbnail
□ Event
□ Producer
□ Consumer
□ Retry
□ Transient Failure
□ Permanent Failure
□ DLQ
□ Idempotency
Streaming
□ Streaming
□ Buffer
□ Buffering
□ Rebuffering
□ Segment
□ Manifest
□ ABR
□ HLS
□ Playlist
□ DASH
□ MPEG-DASH
□ MPD
□ Packaging
Delivery
□ CDN
□ Origin
□ Edge Server
□ Cache Hit
□ Cache Miss
□ Ingress
□ Egress
Playback
□ Device Capability
□ Playback Startup Time
□ Time to First Frame
□ Rebuffering Ratio
□ QoE
□ QoS
Reliability
□ Availability
□ Durability
□ Replication
□ Redundancy
□ SPOF
□ Horizontal Scaling
□ Backlog
□ Throughput
Security
□ Authentication
□ Authorization
□ Access Control
□ Signed URL
□ Signature
□ Expiration
Capacity
□ PB
□ Storage Amplification
□ Tbps
Compute
□ CPU
□ GPU
□ Hardware Acceleration
HTTP
= Hypertext Transfer Protocol
= 超文字傳輸協定
VOD
= Video on Demand
= 隨選視訊
ABR
= Adaptive Bitrate
= 自適應位元率
HLS
= HTTP Live Streaming
= HTTP 影音串流技術
DASH
= Dynamic Adaptive Streaming over HTTP
= 透過 HTTP 進行動態自適應串流
MPEG
= Moving Picture Experts Group
= 動態影像專家組
MPD
= Media Presentation Description
= 媒體播放描述檔
DLQ
= Dead Letter Queue
= 死信佇列
CDN
= Content Delivery Network
= 內容傳遞網路
FPS
= Frames Per Second
= 每秒影格數
Mbps
= Megabits per second
= 每秒 Megabits
QoE
= Quality of Experience
= 體驗品質
QoS
= Quality of Service
= 服務品質
SPOF
= Single Point of Failure
= 單點故障
PB
= Petabyte
= Petabyte 資料容量單位
Tbps
= Terabits per second
= 每秒 Terabits
CPU
= Central Processing Unit
= 中央處理器
GPU
= Graphics Processing Unit
= 圖形處理器
ACID 是四個 Database Transaction Properties 的縮寫：
A
= Atomicity
= 原子性
= All or Nothing
= Transaction 不要只成功一半
C
= Consistency
= 一致性
= Transaction 前後資料應維持已定義的 Rules / Constraints
I
= Isolation
= 隔離性
= Concurrent Transactions 要控制彼此干擾
D
= Durability
= 持久性
= COMMIT 成功後資料應可靠保存
超簡單記：
Atomicity
→ 做一半？不行。
Consistency
→ 留下違反已定義資料規則的狀態？不行。
Isolation
→ 多個 Transactions 互相干擾造成錯誤？要控制。
Durability
→ 都 COMMIT 成功了，資料卻消失？不行。
注意：
ACID 的 Consistency 不代表 Database 自動知道所有 Business
Rules。仍需要 Constraints、Application Logic 與正確的 Transaction
Design 來定義和維護 Rules。
Video Platform 並不是：
Upload MP4
↓
Save
↓
Play
而是一步一步從 Problem 推導：
Large Upload
↓
Chunked + Resumable Upload
Large Binary File
↓
Object Storage
Different Networks / Devices
↓
Transcoding + Multiple Renditions
Slow Processing
↓
Async Processing + Queue + Workers
Streaming Playback
↓
Segments + Manifest
Network Changes
↓
Adaptive Bitrate Streaming
Millions of Viewers
↓
CDN + Edge Cache
Failures
↓
Retry + Idempotency + DLQ + Replication
User Experience
↓
Startup Time + Rebuffering + QoE
核心仍然是：
Requirement
↓
Estimate Scale
↓
Find Bottleneck
↓
Choose Solution
↓
Understand Trade-off
↓
Measure
Design YouTube 的核心不是記住一張 Architecture
Diagram，而是理解為什麼大型 Video 需要 Object Storage、為什麼需要
Transcoding、為什麼 Streaming 要切 Segments、為什麼 Network 變化需要
ABR，以及為什麼 Millions of Viewers 讓 CDN 成為關鍵 Component。
Day 24｜Design Uber：Location Update、Driver Matching、Geospatial
Search 與 Real-Time Trip Tracking 怎麼設計？
會從最基礎開始解釋：
GPS
Latitude
Longitude
Coordinate
Geolocation
Geospatial Data
Geospatial Search
Radius
Distance
Driver Location Update
Location Service
Matching Service
Nearby Driver
Spatial Index
Geohash
Cell
Precision
Real-Time Tracking
WebSocket
ETA
Routing
Trip State
State Machine
Event
Message Queue
Hotspot
Partitioning
Consistency
Idempotency
Availability
例如遇到：
GPS
ETA
API
SLA
也會先按照：
完整英文
↓
每個字的中文
↓
整體中文意思
↓
它是什麼
↓
為什麼需要
↓
簡單例子
↓
System Design 用法
再進入 Architecture。
iThome鐵人賽
看影片追技術