在資深工程師、架構師與技術主管（Staff / Principal Engineer）的求職過程中，系統設計面試（System Design Interview, SDI） 是決定職級與薪酬天花板的最關鍵關卡。
然而，許多技術實力過硬的候選人往往在面試中慘遭滑鐵盧：
- 一聽到題目（例如「設計 Twitter」）就迫不及待在白板上狂畫 Redis、Kafka、MySQL；
- 忽視面試官的真實意圖，單向輸出 40 分鐘，最後發現題目邊界完全理解錯誤；
- 過度堆砌技術名詞，卻無法說明「為什麼選 A 而不選 B」的工程權衡（Trade-offs）。
系統設計面試本質上不是一場單向考試，而是一場模擬在真實生產環境中與資深架構師共同協商解決問題的「技術協作會議」。
本文將為你提供一套標準化的 黃金 4 步法 與 PEDALS 框架，幫助你在 45 分鐘內展現最高水平的工程素養。
1. 45 分鐘標準時間節奏控制（Time Management）
2. 系統設計黃金 4 步法
Step 1: 需求釐清與邊界鎖定（Clarify Requirements & Scope）
面試官給出的題目通常極度模糊（如「設計 YouTube」）。第一步絕對不要畫架構圖！ 必須透過主動提問縮減 Scope：
- 功能性需求（Functional Requirements）：列出核心 2~3 個 MVP 功能（例如：上傳影片、觀看影片、即時按讚；搜尋與留言暫時排除）。
- 非功能性需求（Non-Functional Requirements）：
- 可用性要求（99.99% 高可用 vs. 強一致性）；
- 延遲約束（影片播放啟動延遲
< 500ms）； - 讀寫特徵（極端讀多寫少 100:1）。
- 容量與規模估算（Capacity Estimation）：估算 DAU、QPS、頻寬吞吐與 5 年儲存增量。
Step 2: 高階架構與端到端設計（High-Level Architecture）
畫出簡潔清晰的 Macro-Architecture 全景圖：
- API 契約設計：寫出核心端點的 Request/Response 簽名（如
POST /api/v1/videos/upload）。 - 資料模型（Data Schema）：定義核心實體表與主鍵、索引設計。
Step 3: 核心瓶頸深入剖析（Deep-Dive）
由面試官感興趣的 1~2 個技術難點進行深入展開：
- 資料庫擴展：單庫裝不下怎麼辦？分庫分表（Sharding）依據什麼 Partition Key？如何解決跨分片查詢？
- 熱點問題（Hotspot / Thundering Herd）：百萬粉絲名人發文引發快取擊穿如何防護？
- 故障轉移（Failover）：主庫宕機時如何透過 Raft / MHA 保證零數據丟失？
Step 4: 權衡總結與系統演進（Wrap-Up & Trade-Offs）
主動向面試官總結設計的得與失：
- 瓶頸自我審查：指出系統在 10 倍規模擴展時可能最先爆掉的組件；
- 監控與可觀測性：需要監控哪些 P99 延遲與告警指標；
- 成本權衡：為什麼某些場景選用 S3 Standard 而非 S3 Glacier。
3. PEDALS 記憶口訣框架
在面試緊張時，大腦容易空白。記住 PEDALS 六個字母：
| 字母 | 代表維度 | 核心檢查動作 |
|---|---|---|
| P | Problem Definition | 釐清問題邊界、目標使用者與使用場景。 |
| E | Estimation | 進行 QPS、儲存容量、記憶體與網路頻寬估算。 |
| D | Design Goals | 明確 CAP 偏向、可用性等級與延遲 SLA。 |
| A | Architecture | 繪製高階系統拓撲圖與資料流。 |
| L | Limits & Deep Dive | 尋找單點故障（SPOF）、熱點資料與並發瓶頸。 |
| S | Scaling & Security | 討論水平擴展、分片、快取與安全防護。 |
4. 系統設計面試的 5 大致命紅線（Red Flags）
- ❌ 跳過溝通直接畫圖：被視為「無法在團隊中良好溝通」的嚴重信號。
- ❌ 過早陷入實作細節：在整體架構尚未確定時，過度糾結某個 Redis 資料結構的底層實現。
- ❌ 使用「銀彈」思維：不論任何場景一律只說「用 Kafka」或「加快取」，無法給出替代方案與代價分析。
- ❌ 忽視單點故障（SPOF）：架構圖中存在單節點負載平衡器或未做高可用副本的主資料庫。
- ❌ 防禦性態度：當面試官提出質疑或引導時，固執己見拒絕接受合理反饋。
5. 總結
系統設計面試的核心不是「完美無瑕的標準答案」，而是展示你如何像一位資深架構師一樣思考、拆解複雜問題、控制風險並在無數約束中做出最合理工程權衡的過程。