前言：系統設計沒有標準答案，只有無數的 Trade-offs
不知不覺，這個系統設計系列來到了最終回。
在前面的 11 篇文章中，我們拆解了海量流量的動態牆、CDN 噴錢的短影音平台、不能出錯的支付系統，甚至跨足到了 AI Agent 的大腦推論架構與 CI/CD pipeline。
作為一個即將畢業、正面臨求職挑戰的學生，我在準備系統設計時，最大的感受就是深不見底的焦慮：「天啊，這麼多資料庫、中介軟體和演算法，面試時我怎麼可能全背下來？我也沒有在真實環境扛過一億流量的經驗啊！」
但在經歷無數次的資料搜集、推演與請教前輩後，我意識到一件事：面試官對 Junior / New Grad 的期待，從來都不是要我們默寫出完美的企業級架構。他們想看的，是我們在面對未知與極限時的「思考框架」與「權衡（Trade-offs）能力」。
這篇文章，就是我這段時間備戰系統設計的總結。我把前 11 篇反覆使用的「五維度分析法」，整理成一套應對白板面試的解題框架，希望能幫助到跟我一樣，正在求職苦海中掙扎的開發者。
這篇你可以帶走什麼
- 面試官視角：系統設計面試到底在考什麼？
- 白板面試的 45 分鐘生存指南：五維度萬用解題框架
- 面對「沒有實操過」的領域，如何用第一性原理拆解
- 從 Web 2.0 到 AI-Native，我所體悟到的架構不變本質
核心心法：面試是一場「共同設計」的合作
很多面試者拿到題目（例如：「請設計一個 Twitter」），會立刻衝到白板前，畫下 API Gateway、Load Balancer、Redis 和資料庫分片，然後轉頭看著面試官求認同。
這犯了系統設計面試最大的忌諱：把開放式問題當成了選擇題。
透過模擬面試，我發現面試官更在意的是這三個特質：
- 釐清邊界的耐心（Scope）：在動手前，是否能先冷靜問出系統的限制與日活躍用戶數（DAU）？
- 尋找瓶頸的敏銳度（Bottleneck）：是否能指出自己剛畫出來的架構，在什麼極端條件下會崩潰？
- 闡述權衡的誠實（Trade-offs）：當選擇 Cassandra 而非 MySQL 時，是否清楚知道這會犧牲什麼（例如強一致性）？
為了解決面對未知系統的慌張感，我逼著自己使用同一套紀律來對話，這就是五維度框架的由來。
萬用解題框架：將「五維度分析」帶入白板面試
在充滿壓力的 45 分鐘面試中，這套框架幫助我穩住陣腳。我們可以將五維度，直接對應到面試的 5 個標準推進階段：
階段一、A. 釐清可直接觀察的事實（Requirements & Back-of-the-envelope）
（面試前 10 分鐘） 千萬不要急著畫圖！先框定系統的邊界與流量特徵。
- 功能性需求（Functional）：系統必須能做哪兩三件事？（例如：上傳影片、觀看影片）
- 非功能性需求（Non-functional）：高可用（HA）、低延遲、還是強一致性（Consistency）？
- 封底估算（Back-of-the-envelope）：問出 DAU，快速算出 QPS（每秒請求數）與每日儲存量。這會決定你後面要不要做資料庫分片（Sharding）。
階段二、B. 建立基準條件（High-level Design & Happy Path）
（面試第 10~20 分鐘） 畫出「一般情況下的最佳解」。給出一個能夠滿足 80% 基本需求的高階架構（High-level Design）。
- 畫出 Client、API Gateway、Application Servers 以及底層 Database。
- 向面試官解釋這套「黃金標準」架構（例如經典的 MVC + RDBMS），並確認這是否符合他預期的討論方向。
階段三、C. 尋找反證與破口（Deep Dive & Identifying Bottlenecks）
（面試第 20~30 分鐘 - 決勝點） 這一步是分出 Senior 與 Junior 的關鍵。你要主動攻擊自己的架構！
- 跳脫直覺：「雖然我們用了 MySQL，但當某個大 V 發文時，瞬間會湧入 10 萬次讀取，資料庫連線池會立刻被打爆。」
- 找出單點故障（SPOF）與效能瓶頸，並主動提出引入 Cache（快取）或 Message Queue（訊息佇列）來削峰填谷。
階段四、D. 不確定性與權衡分析（Trade-offs & Edge Cases）
（面試第 30~40 分鐘） 面試官這時會開始施加壓力，改變邊界條件。這時要展現你的「權衡能力」。
- Push vs. Pull 模型：像我們在第 3 篇（時間軸架構）或第 10 篇（CI/CD）提到的，沒有絕對好的模型，只有適合特定場景的折衷。
- CAP 定理的取捨：像第 8 篇（支付系統）為了保證一致性（C）必須犧牲部分可用性；而第 7 篇（短影音平台）為了極致的可用性（A）可以容忍最終一致性。
- 誠實說出你引入的新技術（如 Redis 或 Kafka）帶來了什麼新的維運複雜度或資料不一致風險。
- 對於新鮮人來說，「知道這項技術的缺點」往往比「知道怎麼用」更讓人安心。
階段五、E. 最終結論與演進建議（Wrap-up & Future Scale）
（面試最後 5 分鐘） 總結今天的設計，並提出「如果流量再放大 10 倍，這個系統的下一步演進方向是什麼」。這會讓面試官看到你的架構視野（Vision）。
從 Web 到 AI-Native：技術會變，但第一性原理不變
這 12 篇文章的學習旅程，帶我完整走過了一趟架構的演進史。
- Web 2.0 時代：我們處理的是 HTTP 請求，對抗的是 CPU 與資料庫 I/O 的瓶頸。我們的武器是 Load Balancer、Cache、Sharding。
- 大數據與串流時代：我們處理的是海量事件流，對抗的是吞吐量極限與雙重寫入（Dual-write）不一致。武器變成了 Kafka、Event Sourcing 與微服務解耦。
- AI-Native 時代：來到第 9 篇的 LLM 推論服務，我們處理的是 Token，對抗的是極度昂貴的 GPU 顯示記憶體（VRAM）。武器變成了 Continuous Batching、KV Cache 管理與 PagedAttention。
我發現即使技術名詞從 MySQL 變成了 vLLM，但底層的第一性原理（First Principles）從未改變。
所有的系統設計，本質上都在解決三個問題：
- **運算（Compute）**的瓶頸在哪裡？如何非同步或平行化？
- **記憶體/儲存（Storage）**的瓶頸在哪裡？如何分片或快取？
- **網路（Network）**的瓶頸在哪裡？如何減少傳輸或就近存取（CDN/邊緣運算）？
結語
系統設計是一門沒有盡頭的學問，它既是科學，也是需要大量實戰經驗堆疊的藝術。
這 12 篇筆記雖然無法讓我瞬間擁有十年的維運經驗，但它賦予了我面對龐大未知系統時的「拆解能力」。
希望這套「五維度解題框架」，能成為你我未來面對架構挑戰或嚴苛面試時的底氣。當我們站在白板前，深吸一口氣，從釐清邊界（Scope）開始，自信地展開推演吧！
這是我學生時代第一份大型學習筆記，感謝大家一路以來的閱讀。準備好面對真實世界的挑戰，我們業界見！