系統設計面試先懂這 5 個核心觀念
5 個系統設計核心觀念，幫你在面試與實作中判斷擴充性、可靠性、效能與取捨。
系統設計面試到底先看哪 5 個觀念？
這篇把系統設計拆成 5 個核心觀念，幫你判斷擴充性、可靠性、效能與取捨。
| 項目 | 你要先看什麼 | 常見設計選擇 |
|---|---|---|
| 擴充性 | 流量與資料成長 | 垂直擴充、水平擴充 |
| 可靠性與可用性 | 故障後能否持續服務 | 備援、複寫、自動切換 |
| 一致性與分區容忍 | 分散式環境下的資料正確性 | 偏一致、偏可用 |
| 延遲與吞吐量 | 單次回應時間與整體處理量 | p95、p99、QPS |
| 快取、分片與通訊 | 資料怎麼存、怎麼拆、怎麼傳 | Redis、Shard、REST、gRPC |
1. 擴充性：先問系統能撐多大
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
擴充性是系統設計最先要回答的問題：使用者、資料或流量變多時，系統能不能跟上？這通常會拆成兩條路，vertical scaling 是把單台機器加強，horizontal scaling 是增加機器數量。
面試時講到擴充性，不只是丟名詞，而是要說出容量規劃與成本取捨。單機方案比較直覺，但很快會碰到硬體上限；多機方案比較能長大，卻會引入分散式管理的複雜度。
- 垂直擴充：加 CPU、RAM、儲存空間
- 水平擴充：在負載平衡器後面加更多伺服器
- 彈性擴充：依需求自動增減資源
2. 可靠性與可用性：出問題時還能不能用
可靠性看的是系統能不能持續完成工作，可用性看的是使用者有多常連得上服務。這一項通常會帶出 SLA、SLO 和 SLI，因為團隊需要同一套語言來描述服務健康狀態。
真正重要的是恢復能力。當單一節點、可用區或服務掛掉時，備援、複寫與自動切換能讓系統維持可用，而不是整片停擺。這也是為什麼架構圖不能只畫正常路徑，還要畫故障路徑。
- SLI：你實際量測的指標，例如延遲
- SLO：你希望達到的目標，例如 99% 請求在 200ms 內
- SLA：對客戶承諾的服務條件
3. 一致性與分區容忍：分散式系統最難的取捨
只要系統分散到多台機器，就要面對網路分割、訊息延遲和過期讀取。這時候 CAP theorem 會變成最常被問的框架：在分區發生時，你通常得在一致性和可用性之間做選擇。
這一題很適合拿來看你是否真的懂業務需求。銀行帳本和社群動態牆不能用同一種答案，因為前者偏向資料正確，後者偏向服務不中斷。像 Cassandra、MongoDB 這類資料庫，選擇不同，就是因為工作負載不同。
CAP 取捨例子：
- 銀行帳本：偏一致性
- 社群動態牆：偏可用性
- 網路分割：要能持續運作4. 延遲與吞吐量：快不快和撐不撐得住是兩件事
效能不是單一數字。延遲是單次請求花多久，吞吐量是系統每秒能處理多少請求。看效能時，平均值常常會騙人，所以更常看 p95、p99 這種尾端分位數。
這一項會直接影響你怎麼評估架構。某個設計可能單次回應很快，但一旦流量上來就塞車；另一個設計能吃大量請求，卻因為每一跳都多了一點等待而變慢。真正的判斷方式，是同時看回應時間與總處理量。
- 延遲：單次請求的速度
- 吞吐量：每秒請求數或查詢數
- 分位數：p95、p99 看尾端表現
5. 快取、分片與服務通訊：把系統做大又做順
最後一組觀念，講的是實務上怎麼讓系統維持速度與可維護性。Redis 這類快取可以減少重複計算，分片把大資料拆到不同分區，負載平衡則避免單一主機變成瓶頸。
服務之間怎麼溝通也很關鍵。REST 適合公開 API，gRPC 常用在內部服務呼叫，GraphQL 則讓前端只拿需要的資料。這一層決定資料怎麼流動，不只是資料放在哪裡。
- 快取模式：look-aside、write-through
- 分片鍵：user ID、region、穩定的分區欄位
- 通訊協定：REST、gRPC、GraphQL
哪種適合你
如果你剛開始學系統設計，先抓擴充性和可靠性，因為它們最能幫你建立架構的基本骨架。若你是在準備面試，就把重點放在 CAP 取捨與延遲、吞吐量，這兩類題目最能看出你是否真的理解限制。
如果你是在做產品或後端系統，快取、分片與通訊方式會更值得花時間。這些選擇會直接影響成本、速度和長期維護，通常比換一個框架名稱更重要。