系統設計面試 卷一 System Design Interview（Vol. 1）

📌 30 秒摘要（Layer 3）

系統設計面試系列的第一卷。前半奠定通用能力——如何從 0 擴展到百萬用戶、四步設計框架、粗估容量（這些與 系統設計面試 卷二共用，見既有工具）；後半是一系列經典設計案例（限流器、一致性雜湊、鍵值儲存、唯一 ID、短網址、爬蟲、通知、動態訊息、聊天、搜尋自動補全…），每個案例都沉澱出可重用的設計積木。

🗺 心智圖（Canvas）

系統設計面試卷一

系統設計面試 卷一

Alex Xu｜通用能力 ＋ 經典設計積木

🚀 從 0 到百萬用戶 本書前半的擴展路徑

單機 → 分離 DB → 負載均衡 → 快取／CDN → 讀寫分離 → 分片 每一步都對應一個新出現的瓶頸

🧭 通用框架 （與卷二共用）

工具-系統設計思考框架

🎯 什麼情境該想到我

當你面對「設計一個 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：（待填）

⚠️ 注意

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

🔗 相關工具

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

🧩 設計積木 反覆出現、可重用

工具-一致性雜湊

🎯 什麼情境該想到我

當你要把資料/請求分散到多台節點（快取、分片 DB），又希望「增減節點時不要大搬風」時。

⚙️ 怎麼用

1. 問題：用「hash(key) % N」分配，一旦 N 改變（加/減機器），幾乎所有 key 都要重新對應 → 快取全失效、大量資料搬移。
2. 一致性雜湊：把節點與 key 都雜湊到一個環（0 ~ 2³²）上；key 順時針找到第一個節點。
3. 增減節點時，只影響環上相鄰的一小段 key，其餘不動 → 資料搬移量最小化。
4. 虛擬節點（vnodes）：每個實體節點在環上放多個虛擬點，讓分佈更均勻、避免熱點。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 沒有虛擬節點時容易分佈不均、產生熱點；務必用 vnodes。

🔗 相關工具

• 工具-資料分區 —— 上位問題：先確認要不要分區、按什麼鍵分，一致性雜湊只是其中一種分配策略
• 工具-反熵與Gossip傳播 —— 配套：環上節點增減後，副本之間怎麼把狀態補齊、趨於一致
• 工具-系統設計思考框架 —— 面試或設計時的上層流程，一致性雜湊通常是其中「資料分片」那一步的答案

工具-限流器設計

🎯 什麼情境該想到我

當你要限制「某使用者/IP/API 在一段時間內最多幾次請求」，保護服務不被流量或濫用打垮時。

⚙️ 怎麼用（選演算法）

• Token Bucket（權杖桶）：以固定速率補充權杖，每次請求耗一個；桶有容量 → 允許突發、最常用。
• Leaky Bucket（漏桶）：請求排隊以固定速率流出 → 平滑輸出、不允許突發。
• 固定視窗計數：每個時間窗計數，簡單但視窗邊界會爆量（兩窗交界瞬間 2 倍）。
• 滑動視窗：用滑動時間窗平滑計數，較準但成本略高。

實作要點：分散式下把計數放共享儲存（如 Redis），並回傳 429 Too Many Requests + Retry-After。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 分散式多實例要共享狀態，否則每台各自限流＝實際上限被放大 N 倍。

🔗 相關工具

• 工具-服務容錯設計（限流是容錯的一環）、工具-透明多級分流、工具-系統設計思考框架

其餘積木：唯一 ID 生成 複製與分片 × 訊息佇列

📚 經典案例

限流器 × 一致性雜湊 × 鍵值儲存 唯一 ID × 短網址 × 爬蟲 通知 × 動態訊息 × 聊天 × 搜尋自動補全

💬「好的系統設計，是在明確的約束下 　　做出合理的取捨。」

Link to original

🧰 這本書給我的工具

• 工具-一致性雜湊 — 資料要分散到多節點、又要能平滑增減節點時
• 工具-限流器設計 — 想保護服務不被流量打垮時

通用框架與估算（本書前半亦有）沿用既有卡：工具-系統設計思考框架、工具-容量估算（源自 系統設計面試 卷二，兩卷共用）。

✨ 關鍵重點（Layer 1–2）

• 從 0 到百萬用戶的擴展路徑：單機 → 分離 DB → 負載均衡 → 快取/CDN → 讀寫分離 → 分片。
• 反覆出現的積木：一致性雜湊（資料分佈）、限流（保護）、唯一 ID 生成、複製與分片、訊息佇列。
• 案例導向：每題示範「釐清需求 → 高層設計 → 深入 → 取捨」的完整流程。

💬 金句原文（Layer 0）

• 「好的系統設計，是在明確的約束下做出合理的取捨。」

🔗 相關

• 同系列進階案例見 系統設計面試（卷二）；底層原理見 設計資料密集型應用、資料庫底層原理