系統設計面試 System Design Interview（Vol. 2）

📌 30 秒摘要（Layer 3）

用一個個真實案例（近距離服務、通知系統、支付、搜尋自動補全、聊天…）教你如何在有限時間內，把一個模糊的大題目拆解成可討論的系統設計。真正可帶走的不是某個案例的答案，而是那套通用的思考框架：釐清需求 → 粗估規模 → 畫高層架構 → 深入關鍵元件 → 討論取捨與瓶頸。是把前面資料/架構知識（設計資料密集型應用、鳳凰架構）實戰化的演練場。

🗺 心智圖（Canvas）

系統設計面試

系統設計面試（卷二）

Alex Xu、Sahn Lam｜把大哉問拆成可討論的設計

🧭 四步框架 面對「設計一個 X」的流程

工具-系統設計思考框架

🎯 什麼情境該想到我

當你面對「設計一個 X 系統」這種又大又模糊的題目（面試或實務），不知從何下手時。

⚙️ 怎麼用（四步，別急著畫框）

1. 釐清需求與範圍：功能需求（要做什麼）、非功能需求（規模、延遲、一致性）、圈定範圍。不確定就問。
2. 容量估算：粗估 QPS、儲存量、頻寬（見 工具-容量估算），決定選型量級。
3. 高層設計：畫出主要方塊與資料流（客戶端 → 負載均衡 → 服務 → 快取 → DB → 佇列…）。
4. 深入與取捨：挑 1–2 個關鍵元件深入（如何分區/複製/快取），主動討論瓶頸與替代方案的取捨。

面試/評審看重的是推理與取捨，不是背標準答案。

★ 為什麼「先問清楚」比什麼都重要

系統設計沒有標準答案，只有「在某組約束下的合理選擇」。
約束沒問清楚 → 你的整個設計都建立在假設上，而那些假設多半是錯的。

必問的六個問題：

① 功能範圍：核心功能有哪些？★ 什麼「不做」？
② 規模：  DAU？QPS（平均/尖峰）？資料量？成長率？
③ 讀寫比：★ 讀多寫少（社群）vs 寫多讀少（遙測）→ 架構完全不同
④ 延遲：  p99 要求多少？可以非同步嗎？
⑤ 一致性：★ 可以最終一致嗎？（見 [[工具-線性一致性與共識]]）
⑥ 其他：  合規？多地區？離線支援？成本上限？

★ 第 ③ 與 ⑤ 常常被跳過，但它們對架構的影響最大。

★ 容量估算：要算到什麼程度

目的不是精確，是「決定量級」——決定你需要一台機器還是一千台。

【範例】社群動態，DAU 1000 萬

寫入：每人每天發 0.1 則 → 100 萬則/天 → ★ 平均 ~12 QPS
      尖峰 ×5                        → ★ ~60 QPS        ← 很低！
讀取：每人每天看 50 次  → 5 億次/天  → ★ 平均 ~5,800 QPS
      尖峰 ×5                        → ★ ~29,000 QPS
★ 讀寫比 ≈ 500:1  →  結論：讀取是瓶頸，要重快取與讀取副本

儲存：每則 1KB × 100 萬/天 × 365 × 5 年 ≈ 1.8 TB  ← ★ 單機放得下！
      加上圖片（每則 20% 有圖，每張 200KB）→ ★ 73 TB/5年  ← 這才是大頭
      → 結論：文字進資料庫，圖片進物件儲存 + CDN

★ 要記的基準數字（量級即可）：

1 天	≈ 86,400 秒 ≈ $10^5$ 秒
1 百萬/天	≈ 12 QPS
尖峰倍數	通常 2–10× 平均
單台現代伺服器	可處理 數千～數萬 QPS（依工作量）
單一 PostgreSQL	可撐 數 TB、數萬 QPS（見 工具-資料分區 的警告）

★ 估算最大的價值是「發現不需要複雜方案」：
上面的例子算完會發現寫入只有 60 QPS，單機資料庫綽綽有餘——
整個「要不要分片」的討論消失了。

★ 四步之外：★ 一定要主動講取捨

這是系統設計評審真正在看的東西。 每個決定都用這個句型：

「我選 X，因為在『（約束）』下，Y 的代價是『（具體代價）』。
如果（約束改變），我會改用 Y。」

✅ 「我用 Redis 快取熱門動態，因為讀寫比是 500:1。
     代價是快取失效的複雜度與一致性延遲（使用者可能看到 5 秒前的讚數）。
     如果業務要求即時一致，我會改成 write-through 並接受更高的寫入延遲。」

❌ 「我用 Redis 做快取。」   ← 沒有推理，沒有代價，沒有邊界

★ 逐軸檢查（收尾時用）

設計完之後，用 工具-可靠可擴展可維護 的三軸掃一遍：

可靠性   → 每個元件掛了會怎樣？單點在哪？怎麼回滾？
可擴展性 → 10 倍流量時哪裡先爆？瓶頸是 CPU / 記憶體 / I/O / 網路？
可維護性 → 出事怎麼查？要多少人維運？

★ 再加一個常被忘記的：成本。這個設計一個月要多少錢？有沒有便宜十倍的做法？

★ 常見的失分點

失分	正解
★ 直接開始畫框	先問需求與規模
★ 每個元件都用最複雜的方案	從最簡單能跑的開始，量出瓶頸再加
只講 happy path	主動講失敗模式
背誦「標準架構」	依約束推導
★ 不承認不確定	「這個數字我會用壓測驗證」比編一個精確的假數字好
忽略成本與維運	它們常常是真正的約束

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

• ★ 這是「討論」的框架，不是「實作」的順序。真實專案裡你會邊做邊修，而不是一次設計到位。
• ★ 不要照搬「標準架構圖」。LB → API → Cache → DB → Queue 這張圖適用於很多場景，
  但把它當答案而不是起點，就是在背誦。
• 估算不要算太細。目的是判斷量級。算到小數點只是浪費時間，而且假精確會誤導。
• ★ 先問「能不能不做」。最好的系統設計常常是「這個需求可以用既有的東西解決」。
• 不要一開始就上分散式。單機能解的就單機解——分散式的複雜度成本遠超過多數人的預估
  （見 工具-資料分區、工具-分散式事務的取捨）。
• ★ 給演進路徑。「v0 用託管服務驗證需求，v1 再自建」比一次畫出完整架構更顯成熟。

🔗 相關工具

• 工具-可靠可擴展可維護 —— ★ 收尾時的三軸檢查
• 工具-容量估算 —— 估算的方法
• AI 系統設計框架 —— AI 系統多出來的四個維度與 11 道題的骨架
• 工具-網站架構模式九式 —— 常見的架構手法目錄
• 工具-資料分區、工具-資料複製 —— 擴展的兩個方向
• 工具-服務容錯設計 —— 失敗模式的討論
• 工具-找對數學模型 —— 估算與建模
• 系統設計面試卷一

① 釐清需求與範圍（功能／非功能／規模） ② 粗略容量估算 ③ 高層設計（畫方塊圖） ④ 深入設計 ＋ 討論瓶頸與取捨

📏 粗估規模 先算再選型

工具-容量估算

🎯 什麼情境該想到我

當你要快速判斷「這系統大概多大、需要什麼量級的資源/架構」時（設計前的粗估）。

⚙️ 怎麼用

1. 從使用者/流量推 QPS：日活 × 每人操作數 ÷ 86400 ≈ 平均 QPS；尖峰再 ×2~10。
2. 估儲存：每筆資料大小 × 筆數 × 保存年限；別忘副本與索引開銷。
3. 估頻寬：QPS × 每次回應大小。
4. 記幾個關鍵數字（延遲級距）：記憶體讀 ~100ns、SSD ~100µs、磁碟/網路跨機房 ~ms；讀記憶體比讀磁碟快上萬倍。
5. 只求數量級：目的是判斷「單機夠不夠、要不要分區/快取」，不是精算。

★ 書中的範例：估算推特的 QPS 與儲存量

《系統設計面試》第 2 章的練習（書中特別聲明數字僅供練習，不是推特的真實數據）：

假設：3 億月活躍使用者、50% 每天使用、平均每人每天發 2 則推文、10% 的推文含媒體、資料保存 5 年。

QPS：

• 日活躍使用者 = 3 億 × 50% = 1.5 億
• 推文 QPS = 1.5 億 × 2 ÷ 24 小時 ÷ 3600 秒 ≈ 3,500
• 尖峰 QPS = 2 × QPS ≈ 7,000

媒體儲存（媒體平均 1 MB）：

• 每天 = 1.5 億 × 2 × 10% × 1 MB = 30 TB／天
• 5 年 = 30 TB × 365 × 5 ≈ 55 PB

書給的技巧：四捨五入近似（99987 ÷ 9.1 → 100,000 ÷ 10）、寫下假設、標上單位（「5」是 5 KB 還是 5 MB？）。書強調估算重在過程，不在結果。

★ 心算捷徑

捷徑	數值	用法
一天的秒數	86,400 ≈ 10⁵	每天 X 次 → QPS ≈ X ÷ 10⁵。1 億次／天 ≈ 1,000 QPS
一個月的秒數	≈ 2.5 × 10⁶
一年的秒數	≈ 3 × 10⁷
2¹⁰	≈ 10³（1 KB）	2³⁰ ≈ 10⁹（1 GB），2⁴⁰ ≈ 10¹²（1 TB）

★ 可用性的「幾個 9」：自己算得出來

一年 = 365 × 24 = 8,760 小時；一個月 ≈ 730 小時。

可用性	每年停機	每月停機
99%	87.6 小時（約 3.65 天）	約 7.3 小時
99.9%	約 8.76 小時	約 43.8 分鐘
99.99%	約 52.6 分鐘	約 4.4 分鐘
99.999%	約 5.26 分鐘	約 26 秒

推論：99.99% 代表每月只有 4 分鐘的預算——任何需要人工介入的故障都會超標（光是收到告警、登入、看儀表板就不只 4 分鐘）。所以四個 9 以上必須靠自動故障轉移。

串聯的服務可用性相乘：A（99.9%）呼叫 B（99.9%）→ 整體最多 99.8%。十個 99.9% 的依賴串起來 ≈ 99.0%。

★ 延遲數字的相對量級

書引用 Jeff Dean 2010 年公布的數字，並提醒有些已經過時，但相對快慢仍有參考價值。書整理出的結論：

• 記憶體很快，磁碟很慢。
• 盡量避免磁碟尋道。
• 簡單的壓縮演算法很快。
• 可能的話，資料在網路傳輸前先壓縮。
• 資料中心通常在不同地區，跨地區傳資料需要時間。

★ 估算完之後的用途：換算成架構決策

估算結果	架構推論
寫入 QPS ≈ 7,000 尖峰	單一 PostgreSQL 主機可能撐得住，但要實測；再大一個量級就要考慮分片
30 TB／天的媒體	不可能放資料庫 → 物件儲存 + CDN
55 PB／5 年，再乘上副本數（例如 3 份）	儲存成本是主要的費用項目 → 考慮冷熱分層
讀取量是寫入的 100 倍	快取優先；熱門內容 20% 的資料通常承擔大部分讀取，快取大小可以用這個比例估

最常被忘記的三個乘數：副本數（通常 ×3）、尖峰係數（×2 到 ×10）、成長率（明年的量）。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 估算是為了「選對量級的架構」；別在面試/設計初期糾結精確數字。

🔗 相關工具

• 工具-系統設計思考框架 —— 上位流程，估算是它第二步的固定動作
• 工具-資料分區 —— 估算結果的直接用途：算出單機裝不下，就知道非分區不可
• 工具-時間複雜度分析 —— 姊妹尺，一個估系統資源量級，一個估演算法成長速度

🧱 反覆用到的元件

負載均衡 × 快取 × CDN 訊息佇列 × 分區 × 複製 資料庫選型

⚖️ 取捨心法 考的是推理過程

沒有標準答案 面試考的是「取捨的推理過程」， 不是背某個架構

先簡單再擴展 從能動的最小設計出發， 隨規模逐步加元件 （呼應 [[工具-透明多級分流]]）

📚 案例演練場

近距離服務 × 通知系統 × 支付 搜尋自動補全 × 聊天系統 把 [[設計資料密集型應用]]、[[鳳凰架構]] 的知識實戰化

Link to original

🧰 這本書給我的工具

• 工具-系統設計思考框架 — 面對「設計一個 X 系統」的大哉問時
• 工具-容量估算 — 需要快速估算規模、選型時

✨ 關鍵重點（Layer 1–2）

• 四步框架：① 釐清需求與範圍（功能/非功能/規模）② 粗略容量估算 ③ 高層設計（畫方塊圖）④ 深入設計 + 討論瓶頸與取捨。
• 沒有標準答案：面試考的是「取捨的推理過程」，不是背某個架構。
• 反覆用到的元件：負載均衡、快取、CDN、訊息佇列、分區、複製、資料庫選型。
• 先簡單再擴展：從能動的最小設計出發，隨規模逐步加元件（呼應 工具-透明多級分流）。

💬 金句原文（Layer 0）

• 「先問清楚需求，別急著畫框——沒有需求就沒有正確的設計。」

🔗 相關

• 設計資料密集型應用 —— 底層知識來源，面試答案背後的原理都在那裡
• 鳳凰架構 —— 底層知識來源，分散式事務與服務容錯的完整說明
• 資料庫底層原理 —— 底層知識來源，儲存引擎與共識演算法的細節