Quartz 5

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

Properties1
tagssoftware, system-design, interview, architecture

3 min read

📌 30 秒摘要（Layer 3）

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

🗺 心智圖（Canvas）

系統設計面試

系統設計面試（卷二）

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

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

工具-系統設計思考框架

🎯 什麼情境該想到我

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

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

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

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

🧪 我實際套用的紀錄

  • 2026-07-15：（待填）

⚠️ 注意

  • 最常見錯誤是跳過步驟 1 直接畫架構——沒釐清需求，後面全是猜。

🔗 相關工具

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

📏 粗估規模 先算再選型

工具-容量估算

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

🧪 我實際套用的紀錄

  • 2026-07-15：（待填）

⚠️ 注意

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

🔗 相關工具

🧱 反覆用到的元件

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

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

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

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

📚 案例演練場

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

Link to original

🧰 這本書給我的工具

✨ 關鍵重點（Layer 1–2）

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

💬 金句原文（Layer 0）

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

🔗 相關

Graph View

Backlinks