系統設計
一句話定義
系統設計是把模糊需求、容量約束、資料流、服務邊界、失效模式與工程取捨組成可擴展、可維護、可觀測架構的能力；重點不是背架構圖，而是說清楚為什麼這樣切、哪裡會壞、如何逐步演化。
核心要點
先界定問題，再畫架構
大型系統設計一開始不是選資料庫或畫微服務，而是確認：
| 問題 | 目的 |
|---|---|
| 使用者是誰、核心使用情境是什麼 | 防止把不重要功能放進架構中心 |
| 讀多還是寫多、峰值與平均差多少 | 決定快取、佇列、分片與資料模型 |
| 需要同步還是可延遲 | 決定一致性、佇列、補償與 retry |
| 哪些 failure mode 可接受 | 決定備援、降級、限流與告警 |
| 成本、時程、團隊能力限制 | 決定是否應先用簡單方案，再逐步擴展 |
這讓系統設計與 架構性思考 同源：先把問題邊界與判準拉清楚，再進入方案。
從單機到大規模的演化路徑
2026-05-14-搞定系統設計面試 的第一章用「從 0 到 100 萬用戶」建立一條典型演化線：
- 單伺服器：Web、應用與資料庫都在同一台機器。
- 分離資料庫：應用與資料層分開，讓資源可以各自調整。
- 負載均衡：多台 Web 伺服器共同承接流量。
- 資料庫複製：讀寫分離、提高可用性與讀吞吐。
- 快取與 CDN：把熱資料與靜態內容移近使用者。
- 無狀態 Web 層：把 session / 狀態移到共享存儲，讓應用層可水平擴展。
- 多資料中心：用地理路由與資料同步處理區域可用性。
- 消息佇列：把耗時工作與尖峰流量解耦。
- 監控、日誌、告警與自動化：讓系統變大後仍可被理解與操作。
- 資料分片：當單一資料庫不再足夠時，把資料按 key 拆到多個 shard。
這條路徑的價值不是每個系統都要照順序上所有元件，而是知道「下一個瓶頸通常在哪裡」。
取捨比正解重要
系統設計沒有唯一標準答案，常見張力包括：
- 一致性 vs 可用性：支付 / 帳務與 news feed / 搜尋提示的容錯條件不同。
- 同步回應 vs 非同步處理：使用者需要立即知道結果，還是可以收到稍後通知。
- 簡單架構 vs 預先擴展：過早微服務化可能比單體更難維護。
- 成本 vs 體驗：CDN、多區部署、強一致資料庫都會提高成本。
- 吞吐 vs 延遲：批次處理可以提高吞吐，但可能拉長等待。
好的設計不是「選最強技術」，而是讓取捨對齊需求與風險。
案例是組合題，不是模板題
URL 縮短器、通知系統、聊天系統、網路爬蟲、雲盤、支付與監控看似不同，但都在重複組合 分散式系統元件：
- API / gateway / load balancer
- database / cache / object storage
- queue / worker / retry
- rate limit / dedup / id generation
- metrics / logs / alerting
- consistency / availability / data partitioning
因此學案例的目的不是背「設計 YouTube」或「設計雲盤」，而是看同一組元件如何在不同約束下重新組合。
與其他概念的關係
- 系統設計面試 — 系統設計在面試場景中的呈現方式；要求候選人邊釐清需求、邊展示取捨。
- 可擴展性 — 系統設計最常見的品質目標之一；處理流量、資料量、區域與團隊規模變大時的演化。
- 分散式系統元件 — 系統設計的常用積木庫：負載均衡、快取、CDN、佇列、分片、限流、監控等。
- 封底估算 — 系統設計的前期 sanity check；用粗估 QPS、儲存、頻寬與延遲暴露瓶頸。
- 網頁爬蟲 — 從單機資料抽取升級到分散式爬取系統時，是系統設計案例之一。
- 智慧型API / AI輔助開發 — AI 產品仍要落在真實系統中；模型能力只是元件，可靠服務還需要系統設計。
- MOC-工程 — 本頁屬於工程 MOC 的架構 / 基礎設施軸。
相關來源
- 2026-05-14-搞定系統設計面試 — 本頁主來源；以大型 Web 應用與分散式系統面試案例建立系統設計語法。
備註
未來累積方向：限流器、一致性哈希、分散式唯一 ID、鍵值存儲、消息佇列、物件儲存、監控告警、支付系統、分散式交易、CAP / PACELC、可觀測性與 SRE。先由本頁與 分散式系統元件 承接，等某個子題有 2+ 專門來源或成為查詢高頻點再拆頁。