前面有討論了 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。值得注意的是「計算上其實都有一些小技巧」和「既有數值推估」可以去留意。
在做 System Design 時，可以有幾個階段來協助思考，分別是：
- 釐清探索需求 Requirement，其中有還有分功能需求 和 非功能需求
- 架構 High-Level Architecture Design
- Detail Deep dive
除了以上事情之外，其實定義出「什麼不在討論範圍內 (out of scope)」也是非常重要的，可以展示出「排定優先順序的能力」。雖然 System Design 範圍很大，但其實也是有不少模板和套路可以練習。可以多看看各式各樣系統的 high-level 設計，順便把其中自己不熟悉的知識補上。
