系統設計面試 卷一

🎯 什麼情境該想到我

當你面對「設計一個 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 倍。

🔗 相關工具

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