🎯 什麼情境該想到我
當你面對「設計一個 X 系統」這種又大又模糊的題目（面試或實務），不知從何下手時。
⚙️ 怎麼用（四步，別急著畫框）
- 釐清需求與範圍：功能需求（要做什麼）、非功能需求（規模、延遲、一致性）、圈定範圍。不確定就問。
- 容量估算：粗估 QPS、儲存量、頻寬（見 工具-容量估算），決定選型量級。
- 高層設計：畫出主要方塊與資料流（客戶端 → 負載均衡 → 服務 → 快取 → DB → 佇列…）。
- 深入與取捨：挑 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 秒 ≈ 秒 |
| 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 道題的骨架
- 工具-網站架構模式九式 —— 常見的架構手法目錄
- 工具-資料分區、工具-資料複製 —— 擴展的兩個方向
- 工具-服務容錯設計 —— 失敗模式的討論
- 工具-找對數學模型 —— 估算與建模
- 系統設計面試卷一