由於 Video streaming 是會消耗大量頻寬，用戶又對延遲敏感，故為了達到比較流暢的觀看體驗，主要會討論:
- Streaming protocol : 如 HLS、DASH 這些 Adaptive bitrate streaming(ABS)，允許 player 不需要等待整個影片下載完成才播放，而是可以同時下載多個「影片小片段」，這時就可以開始觀看，並且根據即時網路狀況和裝置功能動態地在品質等級之間切換
- CDN : 絕大多數視訊流量由靠近用戶的 CDN 邊緣節點提供服務，這是影響成本和延遲最重要的部分
最後是關於串流防盜，當影片和串流媒體僅依賴 URL 存取時，資料不僅容易拷貝，還容易發生未經授權的觀看分享，尤其是對於付費內容更需要注意，故安全性如何保證也是一個重要的議題。
前面有討論了 Video Sharing Platform 大概的 Data FlowIn 設計，接著繼續深入「影片上傳」這個部分的細節和實作。並不只是簡單的把檔案藉由後端 server 寫進儲存系統而已，還牽涉到如：
- 安全性相關 : User 驗證、Data 驗證等等
- 錯誤處裡: 上傳網路中斷、資料格式不符、error handling
- 資料轉換: 對應需求，可能對資料做前處理或後處理
- 系統能力: Latency 或者是否影響 server 穩定
應視為一條長流程、非同步、且容易受到網路品質影響的工作，而不是單次同步請求，這樣才能應對各種狀況。
如果要 Design 一個 Video Sharing Platform，首先要釐清影片是哪種類型，例如: 短影片(Shorts / Reels / TikTok)、長影片(YouTube)、直播(Twitch、17LIVE) 這裡就先選一個比較簡單的「短影片平台」來做範例，而其 Function Requirements 和 Non-Function Requirements 分別就是 :
- 達成 Data FlowIn/FlowOut 設計，在這裡代表是「 User 可以去上傳自己創作一些 Video 」而「 其他 User 可以去觀看 Video 」
- 確保有大量 User 使用時系統也要穩定，故有要求 Scalability ; 影片也希望播放順暢，故 latency 要求不能太高
前面寫的 System Design: Scalability講述了如何擴展 DB 來承擔流量，接下來要討論如何去設計系統來提高效能 (Performance)，延遲的影響對於使用者體驗也是一件需要注意的重要事情，主要是使用兩個衡量指標爲：延遲度 (latency) 與吞吐量 (throughput)。
理想的狀況來說，低延遲與高吞吐 (low latency and high throughput) 是軟體系統設計的主要目標，而 Latency 主要是受到 「運算時間」和「傳輸時間」兩大因素影響，常用的解決套路是使用 cache 機制。
一旦使用者逐漸增加，線上應用流量開始因為業務而持續上升，多到系統無法承受時，就需要讓系統具備擴充能力，來要關注怎麼樣去做 scaling，或者說可伸縮性 Scalability ，其中又有「垂直擴充 Vertical scaling」 和「水平擴充 Horizontal scaling」 兩種擴充方向。 Vertical scaling 是直接給機器換上像是更強的 CPU、更多的記憶體、更大的硬碟等等，但這個通常不是系統設計想考察的 ; 通常說的 Scalability 都是指 Horizontal scaling（簡稱 Scaling），而此方式可以細分成以下三種方法 :
- 增加副本 replication : 將資料複製成多份 Scale Cube ，放在更多的地方
- 資料分區 sharding : 會在每台機器上會保留一部分資料
- 功能分區 functional partitioning : 將一個系統按照功能，去拆分為更小的子系統，也稱 Federation
back-of-the-envelope calculations 中文翻譯是「粗略估算」，英文字面上的意思就是在一張信封後面就能隨手計算這樣，雖然簡單但卻一定要有一些事實根據來判斷和計算數字。真的開始在系統設計之前，有機會先得到一些參數，再來會需要由這些假設的參數來當定錨點，「估算一下」系統性能會需要承擔多少，例如有以下常見的指標:
- QPS(Queries Per Second)
- Latency
- Storage Size
- Network bandwidth
這些不僅幫助我們了解系統設計的邊界，也讓我們掌握系統在不同併發情境下的 performance。值得注意的是「計算上其實都有一些小技巧」和「既有數值推估」可以去留意 ！
