系統設計面試：一套可以重複使用的框架
系統設計這一關沒過的人，大多不是因為不知道快取是什麼，而是因為講散了。沒有結構，四十五分鐘就消失在問題的某一個角落，面試官始終沒看到廣度。這篇給你一套幾乎任何題目都能照著跑的框架、六道一再出現的題目，以及那些悄悄拖垮強應徵者的錯誤。
為什麼結構比知識重要
資深面試官打分數的不是「你的方案是不是那個正確答案」——根本沒有那個答案。他在看你怎麼想：動手之前會不會先釐清、會不會推理取捨、知不知道瓶頸在哪裡。一個從容地把一份普通方案講清楚的人，分數通常比一個懂得更多、卻跳來跳去的人高。結構本身就是訊號。
公開的指引講的也是這件事。Meta 寫明它的設計面試是 45 分鐘，幾乎從不寫程式；Amazon 的 SDE II 準備頁面說至少會有一道系統設計題，並建議透過提問來補齊和驗證你的設計；Google 的 SRE 工作手冊在談大型系統設計時強調，合理的推理和假設比任何最終數字都重要。
每次都照著跑的那套框架
時間大致照這個順序分配。比例比具體分鐘數重要。
- 釐清需求（約 15%）。把功能性需求（「使用者可以發文和追蹤」）和非功能性需求（規模、延遲、一致性、可用性）分開。要一個粗略的數字：多少使用者、讀寫比、一筆資料多大。
- 估算規模（約 10%）。做信封背面的算術：每秒請求數、一年的儲存量、頻寬。它決定整份設計——100 QPS 和 100 萬 QPS 是兩道不同的題目。
- 定義介面和資料模型（約 15%）。幾個 API 端點，加上核心實體。後面所有東西都錨在這裡。
- 畫出整體架構（約 25%）。用戶端、負載平衡器、服務、資料庫、快取、佇列。先保持簡單——哪裡被追問，再往哪裡加深度。
- 在關鍵處深入（約 25%）。挑出那個有意思的瓶頸鑽進去：熱門讀取路徑、寫入擴散（fan-out）、儲存選型。資深的訊號就住在這一段。
- 收在瓶頸和取捨上（約 10%）。單點故障、熱點、一致性與可用性的取捨。順便講出你會監控什麼。
你會一再伸手去拿的那幾根槓桿
幾乎所有設計都是由同樣幾塊拼起來的。關鍵是知道每一塊在什麼時候才該上場：
- 快取——降低讀取延遲和資料庫壓力；要談失效和過期資料。
- 負載平衡——分攤流量；無狀態服務的水平擴展。
- 副本（Replica）——可用性和讀取擴展；代價是一致性的延遲。
- 分片（Sharding）——把寫入和儲存擴展到單機之外；小心熱點分片。
- 訊息佇列——解耦生產者和消費者；削峰；把重的工作變成非同步。
- CDN——把靜態和可快取的內容推到離使用者近的地方。
本事不在於把這些名詞列出來，而在於講清楚這道題到底需要哪幾個，以及每一個各自的代價。
一再出現的六道題
如果這六道你都能從容地設計出來，大部分的變體你也接得住：
- 設計一個短網址服務（key 產生、轉址讀取路徑、點擊統計）。
- 設計動態消息 / Feed（寫入擴散還是讀取擴散、排序、名人熱點）。
- 設計即時通訊系統（送達保證、上線狀態、訊息順序）。
- 設計限流器（token bucket、分散式計數）。
- 設計檔案儲存與分享（中繼資料和大型物件分離、去重、一致性）。
- 設計叫車或附近搜尋（地理索引、媒合）。
它們一再出現，是因為每一道都逼你面對不同的取捨——寫入擴散、地理索引、送達語意。想看即時助手在這類題目上怎麼把回答結構化，可以看我們的系統設計面試 AI 頁面。
悄悄扣掉你分數的錯誤
- 還沒釐清就開始蓋。在不知道讀寫比之前就跳到資料表結構，是經驗不足的訊號。
- 每個地方都很淺。十個元件各碰三十秒，等於沒有深度。挑一個，鑽進去。
- 不講數字。沒有估算支撐的「這個撐得住」，什麼都沒說。
- 沒有取捨。每一個選擇都有代價。「我會加快取，但它會帶來過期資料，我用比較短的 TTL 把它兜住」——這句話本身就是全部功夫所在。
- 沉默。面試官只能替講出來的東西打分數。把你的思考講出來。
怎麼練
從上面的清單挑一題，出聲把整套框架從頭跑到尾，限時四十五分鐘——最好用白板或一份空白文件，不看筆記。錄下來，或找個夥伴。然後檢討時間到底花在哪裡：大多數人會發現自己在資料模型上耗了三十分鐘，根本沒走到擴展那一步。換不同類型的題目練個五次，這套結構就會變成肌肉記憶——而肌肉記憶正是那天讓你騰出腦袋去真正思考的東西。
資料來源
- Meta Careers — Preparing for your software engineering interview at Meta — 技術初篩的形式和時間分配、45 分鐘的設計和行為面試、「邊想邊講」（查證於 2026-10-14）
- Amazon Jobs — SDE II interview prep — 線上測驗、四場 55 分鐘面試、至少一道系統設計題（查證於 2026-10-14）
- Google SRE Workbook — Non-Abstract Large System Design — Google SRE 怎麼做大型系統設計；推理比最終數字重要（查證於 2026-10-14）
FAQ
系統設計面試該怎麼組織回答？
每次都走同一條路：先釐清需求和規模、定義介面、畫出資料模型，再畫整體元件，然後在面試官追問的地方深入，最後收在瓶頸和取捨上。被打分數的正是結構——一條熟悉的路，能讓你在陌生領域裡不至於僵住。
系統設計要講到多細？
細到足以替每個選擇辯護，但不必把整個系統設計完。把取捨講出來——一致性還是可用性、讀取路徑還是寫入路徑、成本還是延遲——只在被要求的地方再往下鑽。
最常見的系統設計錯誤是什麼？
還沒問規模就開始畫圖、只列技術名詞而不推理，以及忽略故障情境。講出「加一個佇列」不是設計；講清楚佇列塞住時會發生什麼，才是。
系統設計要怎麼練？
挑一個你熟悉的產品，照同一套框架出聲設計四十分鐘，然後每週換一個再來一次。練那條路線，比背下各種架構更重要。