系統設計方法論與容量估算#

面對一道開放式系統設計題，最容易犯的錯誤是「還沒釐清需求就開始畫架構」。本節整理一套可重複套用的四步驟框架，搭配「信封背面估算 (Back-of-the-envelope Estimation)」常用的記憶表，讓你在白板前能快速把規模、延遲、可用率換算成具體的設計取捨。

本節是後續案例（限流器、一致性雜湊、發號器、鍵值儲存）共用的「前置動作」。

四步驟框架#

flowchart LR
    S1["1. 釐清需求<br/>Understand &<br/>Scope (3-10 min)"]
    S2["2. 高階設計<br/>High-level Design<br/>(10-15 min)"]
    S3["3. 深入細節<br/>Design Deep Dive<br/>(10-25 min)"]
    S4["4. 收尾<br/>Wrap Up<br/>(3-5 min)"]
    S1 --> S2 --> S3 --> S4
    S3 -.重新釐清.-> S1

深入細節時若發現需求不清，要回到步驟 1。 系統設計不是線性流程；在步驟 3 暴露的歧義（例如「排序規則」「媒體型別」）往往會推翻步驟 2 的藍圖。

釐清需求問題清單#

在動筆前，至少要問清楚這幾類問題：

• 我們要做哪些具體功能？哪些是最重要的核心功能？
• 目前有多少使用者？預期 3 個月 / 6 個月 / 1 年的成長到多大規模？
• 流量規模（DAU、QPS）大概多少？讀寫比例如何？
• 支援哪些媒體型別（純文字、圖片、影片）？
• 結果如何排序 / 排名？
• 是行動 App、Web，還是兩者都要？
• 公司現有技術棧是什麼？有哪些既有服務可以直接複用？

信封背面估算#

2 的次方記憶表#

資料量單位本質是 2 的次方，但估算時常以 10 進位近似：

常見延遲數字#

「每位工程師都該知道的延遲數字」——記住數量級就能判斷瓶頸在哪：

三條啟示：記憶體快、磁碟慢（避免 disk seek）；傳輸前先壓縮；跨資料中心 / 跨洲的 RTT 是設計多區域系統的硬性下限。SSD 隨機讀約 150 µs，介於記憶體與磁碟之間，這也是 鍵值儲存 用 SSTable + Bloom filter 的前提。

可用率 ↔️ 停機時間#

非功能需求中最常被量化的是可用率 (Availability)，習慣以「幾個 9」表示：

每多一個 9，成本與架構複雜度往往呈非線性上升（冗餘、故障切換、跨區複製）。可用率與一致性的取捨屬 CAP 範疇，理論細節見 分散式系統基礎 — CAP 定理。

QPS、尖峰與儲存估算#

估算的核心是把「使用者行為」逐步換算成「每秒請求數」與「總容量」：

$$ \text{DAU} = \text{MAU} \times \text{每日活躍比例} $$

$$ \text{平均 QPS} = \frac{\text{DAU} \times \text{每人每日操作數}}{86400} $$

$$ \text{尖峰 QPS} \approx 2 \times \text{平均 QPS} $$

$$ \text{儲存量} = \text{DAU} \times \text{每日操作數} \times \text{單筆大小} \times \text{保留天數} $$

小結#

估算的目的不是算到小數點正確，而是得到正確的數量級，好讓你判斷「要不要快取、要不要分片、要不要多區域」。數字本身會引導出架構。