前端系統設計面試：在沒有正確答案時做決定並說清楚取捨

1. 卡住的不是知識，是選擇 0:00–2:13

作者指出很多前端工程師在系統設計面試i卡住，不是因為懂得太少，而是因為看得到太多合理選項：cursor 還是 offset 分頁？WebSocketi 還是輪詢i？他們相信有一個「正確架構」藏在某處，只要念夠多理論就能找到。但面試官多半不是在找完美答案，而是看你能不能理解問題、做出合理決定、講清楚取捨i、然後繼續往前推進。

推理作者從讀者的實際體感切入：一被問到「設計一個系統」，腦中冒出的不是空白，而是一串二選一——cursor 還是 offset 分頁？WebSocket 還是輪詢？資料要正規化還是保持巢狀？要不要加快取？該從簡單方案開始，還是那樣顯得太資淺？他接著點出一個反直覺的因果：懂得越多越難受，因為你看得見越多可行選項。所以卡住的原因不是知識不足，而是有好幾個都說得通的選項，卻不知道怎麼選一個、講清楚、然後往前走。這些人心裡假設有一個「正確架構」藏在某處，只要理論念夠多、題目練夠多、想得夠久就會找到——而作者說，那通常不是系統設計面試在測的東西。面試官多半想看的是四件事：能不能理解問題、做出合理決定、解釋取捨、並持續推進。

• C卡住不是知識不足，而是看得見多個都說得通的選項卻不知道怎麼選一個、講清楚、往前走→ 畫地圖
• Ctrade-off：會讓人癱瘓的都是「沒有絕對優劣、只有適用情境」的成對選項→ 畫地圖
• E面試官多半看四件事：理解問題、做合理決定、解釋取捨、持續推進→ 存＋演練
• Roffset 與 cursor 分頁的差別→ 存＋回想

AI 補充值得注意的是作者在這裡偷偷做了一次「問題重寫」，這是全片最關鍵的一步。原本的問題是「我要怎麼背下某類題目的正確設計」，被改寫成「需求不完整時，我要怎麼做出合理決定並清楚解釋取捨」。這兩個問法的差別在於可行性：第一個問題沒有終點，因為題型無限；第二個問題有明確的可練習動作。另外作者列出的那串二選一並非隨機——它們全都是「沒有絕對優劣、只有適用情境」的成對選項。會讓人癱瘓的正是這種題目：如果有一個選項客觀更好，你根本不會猶豫。

術語:offset-based paginationicursor-based paginationi

2. 真實工程不是選擇題 2:13–3:31

真實專案永遠帶著限制：既有 codebase、團隊結構、成員經驗落差、公司已選的技術棧。紙上看起來漂亮的方案，導入成本可能太高。所以真實世界沒有完美答案，只有「對這個產品、這個團隊、這些限制而言合理」的方案。這也解釋了為什麼有能力的工程師反而卡住：他們看得到太多取捨，於是不斷列選項、不斷比較，等待對方確認。討論取捨是好事，被困在取捨裡不是。

推理因為上一段把問題重寫成「資訊不完整時怎麼決定」，作者接著要證明資訊不完整才是常態。他的論證方式是把真實專案的起點攤開：開始一個專案時，你面對的是一個真實問題——產品問題、使用者痛點、或必須解決的商業需求——而且一進入真實工作，限制就一定在：既有的 codebase、團隊結構、成員經驗落差、公司已經在用的技術棧、資料庫或平台。有時方案紙上很漂亮，但導入成本太高。結論因此成立：真實軟體裡通常沒有完美答案，只有「對這個產品、這個團隊、這些限制而言說得通」的方案。而這正好解釋了上一段那個反直覺現象——有能力的工程師之所以卡住，是因為他們懂得多到不敢隨便下手，看得見很多選項與取捨，於是不斷列、不斷比，本該往前推的設計就停在原地等一個確認。作者下了明確的界線：討論取捨是好事，困在取捨裡不是。

• Cconstraint：既有 codebase、團隊、技術棧、導入成本——全在技術之外，卻決定方案勝負→ 畫地圖
• A「討論取捨是好事，困在取捨裡不是」：像在餐廳看菜單太久，桌上什麼都沒上→ 批判類比
• Rtotal cost of ownership：不只寫程式的時間，還有每次上線、除錯、招人、交接的持有成本→ 存＋回想

AI 補充作者這裡的論證是「取消前提」而不是「回答問題」：他沒有教你怎麼找到正確答案，而是拆掉「有正確答案」這個假設。這一步值得留意，因為它同時解釋了為什麼練更多題目沒有用——如果解取決於情境，那麼可背誦的解就不存在。另外，作者把限制列成清單但沒有明說它們的共同性質：這些限制全都不在技術本身，而在技術之外（人、既有系統、時間、成本）。這帶出一個實務上的判準：當兩個方案技術上難分高下時，決定勝負的通常是團隊會不會維護它，而不是它跑得多快。還有一件作者只點到的事——他說「導入成本太高」，這個成本不只是寫程式的時間，而是往後每一次上線、除錯、招人、交接都要付的持有成本。

術語:constraintianalysis paralysisitotal cost of ownershipi

3. 例一：分頁 — 搜尋結果 vs 動態牆 3:31–5:39

第一個例子是分頁i。「該用哪種分頁策略」聽起來有標準答案，其實取決於產品。搜尋結果頁的使用者需要位置感：想翻下一頁、回上一頁、比較列表不同段落，page-based 分頁符合他們的心智模型i。動態牆（feed）則相反：使用者不會想「跳到第七頁」，只是持續往下看，新內容還會不斷長出來，所以 cursor-based／無限捲動i是比較好的起點。同樣是長列表，產品體驗、使用者行為、資料出現方式都不同，分頁策略自然不同。關鍵句是「我會從這裡開始」，而不是「這是唯一解」。

推理因為上一段確立了「解取決於情境」，作者接著要示範情境怎麼決定解。他刻意挑一個聽起來有標準答案的問題——「我們該用哪種分頁策略？」——然後把它拆成兩個產品來看。搜尋結果頁：使用者搜尋、拿到一串結果，通常想要清楚的位置感，想翻下一頁、回上一頁、比較列表不同部分的結果；在這種體驗裡 page-based 分頁說得通，因為「頁」這個概念符合使用者的心智模型，給他位置感，也讓他容易回到結果集的特定位置。動態牆（feed）則完全相反：使用者不會想「我要去第七頁」，他只是持續消費內容，新內容還會隨時間冒出來、列表不斷長大，所以持續往下捲才自然，cursor-based 載入或無限捲動是比較好的起點。作者把對照的結構點明：兩邊都是長列表資料，但產品體驗不同、使用者行為不同、新資料出現的方式也不同，所以分頁策略可以不同。最後他要讀者注意一個措辭——「我會從這個方向開始（start with）」，而不是「這是唯一可能的設計」；意思是依目前需求，這是合理的基準線，需求變了就回頭重新檢視。

• Ccursor-based pagination 指向資料本身的位置，對「翻頁期間資料位移」天生免疫→ 畫地圖
• E搜尋結果要位置感→page-based；動態牆持續長新內容→cursor＋無限捲動→ 存＋演練
• Efeed 用 offset 分頁時，新貼文插到最前面會讓使用者往下捲時重複看到同一則→ 存＋演練
• R「我會從這個方向開始（start with）」把決定從宣稱最佳降級成可修正的起點→ 存＋回想

AI 補充這個例子之所以有說服力，是因為兩種分頁的技術代價剛好對上兩種產品的使用方式，而作者沒有把這層講滿。搜尋結果通常是一次查詢的靜態快照，資料在你翻頁時不太會變，所以 offset 分頁「翻頁期間資料位移」的弱點在這裡幾乎不發生；而它能跳到任意頁的能力，正好是使用者要的。動態牆恰恰相反：新貼文隨時插到最前面，用 offset 的話你往下捲時會重複看到同一則貼文——這是真實可觀察的 bug，不是理論疑慮；cursor 因為指向資料本身的位置，天生免疫。所以「取決於產品」不是含糊其詞，而是可以推導的：先看資料變動頻率與使用者的移動方式，技術選擇會自己浮現。另外「start with」這個措辭比它看起來重要得多——它把一個決定從「宣稱最佳」降級成「可修正的起點」，同時免除了你必須正確的壓力，這正是第 2 段那種分析癱瘓的解藥。

術語:page-based paginationi

4. 例二：即時協作 — 白板 vs 看板 5:39–7:41

第二個例子是即時協作i。該用 WebSocket 嗎？需要衝突解決i嗎？CRDTi 還是 OT？答案一樣看產品。白板類應用裡使用者同時畫、拖、改、移動物件，更新非常頻繁且細粒度，常常動到同一塊區域，因此同步要求高、衝突處理與順序都很重要。Trello／Jira 這種看板則是搬卡片、改標題、留言、指派，同樣是協作、同樣需要即時更新，但互動沒那麼連續、衝突好推理，簡單模型往往就夠。可能還是用 WebSocket，但不需要白板那種等級的衝突解決複雜度。

推理因為分頁的對照已經成立，作者接著用同一個結構檢驗更難的題目：即時協作也是大家常常在找「最佳解」的領域——該用 WebSocket 嗎？需要衝突解決嗎？要 CRDT 還是 operational transformationi？他說這些都值得懂，但答案仍然取決於產品，然後擺出第二組對照。白板類應用（如繪圖、設計工具）：使用者同時畫、拖、編輯、移動物件，更新非常頻繁且細粒度，人們可能幾乎持續地互動在同一塊區域；這種產品的同步要求高得多，衝突處理很重要、順序也很重要，系統必須讓協作既順暢又正確。看板類應用（Trello、Jira）：使用者把卡片在欄位間搬動、改標題、加留言、指派某人、更新狀態；一樣是協作、一樣需要即時更新，但互動模式很不一樣——更新通常沒那麼連續、衝突也比較好推理，很多情況下簡單模型就夠了。你可能還是會用 WebSocket、還是需要即時同步，但不需要跟白板或設計工具同一等級的衝突解決複雜度。作者由此下結論：即時協作沒有普世答案，取決於是哪一種協作、更新多頻繁、使用者對產品的期待是什麼。所以把系統設計面試當成面試官在偷偷等一個魔法答案，是危險的；更強的做法是展示你怎麼想、怎麼做取捨、怎麼依情境調整設計。

• C衝突的機率 × 衝突的代價，共同決定你需要多複雜的 conflict resolution→ 畫地圖
• E白板：高頻細粒度、常同時動同一物件→需 CRDT/OT；看板：離散動作、少撞→後寫覆蓋就夠→ 存＋演練
• R「怎麼傳」（WebSocket）與「衝突怎麼解」（CRDT/OT/LWW）是兩個獨立的決定→ 存＋回想
• RCRDT 與 operational transformation 的差別→ 存＋回想

AI 補充這一組對照的關鍵變數，作者提到了但沒有命名：兩人同時動到「同一個東西」的機率。白板上兩個人同時改同一個形狀的位置與大小是常態，所以你需要一套能把兩筆並發修改合併成一個合理結果的機制（這正是 CRDT 與 OT 在做的事）；看板上兩個人同時改同一張卡片的同一個欄位則罕見，所以「後到的覆蓋先到的」這種最簡單的規則，出錯機率低到可以接受。判準因此可以量化成一句話：衝突的機率與衝突的代價，共同決定你需要多複雜的衝突解決。這也補上了作者跳過的一步——他說看板「衝突比較好推理」，理由其實是看板的操作大多是彼此獨立的離散動作（搬一張卡、改一個欄位），而白板的操作是連續且互相依賴的（一連串座標變化）。另外值得指出：作者把 WebSocket 與衝突解決拆成兩個獨立決定，這件事本身很有價值——很多人以為選了即時同步就得整套上，其實「怎麼傳」和「衝突怎麼解」是可以分開決定的兩個維度。

術語:last-write-winsi

5. 解法三步驟：釐清、選擇、解釋 7:41–8:22

作者給出替代做法：Clarify、Choose、Explain 三步。第一步是釐清需求——先別急著解，花點時間搞懂這是什麼系統、要設計的使用者體驗是什麼、規模／一致性／交付速度各有多重要、真正的限制是什麼。很多虛弱的系統設計回答，都是因為太早開始解題。

推理因為前兩個例子已經把「依情境決定」證明完畢，作者接著回答那個實作問題：那該怎麼做？他給出三步——Clarify、Choose、Explain。這一段先講第一步：釐清需求。在跳去解法之前，花點時間搞懂這是什麼樣的系統：我們要設計的使用者體驗是什麼？規模、一致性、交付速度各有多重要？我們真正有哪些限制？他下了一個直接的診斷：很多虛弱的系統設計回答，都是因為太早開始解題。

• CClarify → Choose → Explain：資訊不完整時仍能推進的三個動作，也是資深工程師的日常→ 畫地圖
• PClarify：跳去解法前先問三個問題，蒐集真正會翻轉答案的變數→ 練習
• Cnon-functional requirements（效能、規模、一致性、可用性、時程）才是架構的真正驅動力，最常被省略→ 畫地圖

AI 補充把作者列的三個問題對回前面的例子，就會看出它們不是泛泛的清單：「要設計的使用者體驗是什麼」正是分頁例子裡分辨搜尋結果與動態牆的那個問題；「規模、一致性、交付速度哪個重要」正是即時協作例子裡決定要不要上 CRDT 的那個問題；「有哪些限制」則是第 2 段整段的內容。也就是說，釐清階段問的東西，就是前面被證明會翻轉答案的那些變數——所以這一步不是禮貌性暖身，而是在蒐集決策真正需要的輸入。實務上有個好用的補充：把需求分成功能性（系統要做什麼）與非功能性（要做得多快、多可靠、多能擴展），後者才是架構的真正驅動力，也最常在題目裡被省略、需要你主動去問。另外「太早開始解題」在面試裡有個明顯症狀——三十秒內就開始講技術名詞。

術語:non-functional requirementsipremature optimizationi

6. 選一個合理起點：steel thread 8:22–9:04

第二步是選一個合理的基準線，不是最進階、最炫的方案，而是依目前所知說得通的起點。這裡用得上 steel threadi：先做出最薄的端到端可運作方案，等需求明確把你推過去，才加複雜度。例如搜尋結果先用 offset 分頁（好實作、好理解），動態牆先用 cursor 載入，先用一般 request-responsei API，等即時需求明確到足以justify 才引入 WebSocket。這種回答顯示成熟度：不是為了聽起來聰明而加複雜度，而是讓方案match問題。

推理因為上一段確立了「先釐清再解題」，作者接著處理第二步：選一個合理的基準線。他特別強調不是最先進、也不是最令人印象深刻的方案，只是一個依目前所知說得通的起點。這裡他搬出 steel thread 的概念：先做出最薄的端到端可運作方案，之後只有在需求明確把你推過去時才加複雜度。然後他把這個原則套回前面兩個例子：搜尋結果也許先用 offset 分頁，因為好實作、好理解；動態牆也許先用 cursor 載入；即時性的部分也許先用一般的 request-response API，等到即時需求明確到足以正當化它時，才引入 WebSocket。作者說這種回答顯示成熟度：你不是為了聽起來聰明而加複雜度，而是讓方案配合問題。

• Csteel thread：先做最薄但貫穿介面→API→資料→畫面的可運作路徑，等需求推你才加複雜度→ 畫地圖
• PChoose：選一個依目前所知說得通的起點，不是最先進的方案→ 練習
• Asteel thread 不等於「先做個簡單版本」，差在「端到端」三個字→ 批判類比
• RYAGNI：在真正需要之前不要先實作某個功能或抽象→ 存＋回想

AI 補充steel thread 之所以比「先做個簡單版本」更有力，在於「端到端」這三個字：它要求你的第一版必須貫穿整條路徑（介面 → API → 資料 → 回到畫面），哪怕每一段都很粗糙。這帶來一個具體好處——整條鏈上的未知數會在最便宜的時候先暴露出來，而不是等到你把某一層做得很精緻之後，才發現另一層根本行不通。這也讓它在面試裡特別好用：先把最薄的一條線講完，你就有了一個完整可討論的設計，接下來每一次加複雜度都能綁在一個具體理由上（「因為要支援離線編輯，所以這裡要換掉」）。要注意作者措辭裡的方向性——「等需求把你推過去」意味著複雜度需要被觸發，而不是被預測；這正是第 5 段那個過早優化的反面。從第 3 段的角度看，這裡也隱含著一個溫和的取捨：offset 分頁在資料會變動時有其弱點，但「好實作、好理解」在起步階段是真實的價值，且之後換成 cursor 的成本並不高——這正是可撤回決定的典型樣貌。

術語:walking skeletoniYAGNIi

7. 把取捨講清楚 9:04–10:06

第三步是清楚說明取捨，這是強回答的核心。你不必假裝自己的選擇完美，通常不假裝更好。可以說：這是我會開始的方案、為什麼它符合目前需求、我接受哪些取捨、什麼情況下我會回頭重新檢視這個決定。這比列出五個方案然後等面試官告訴你哪個對強得多，因為你聽起來像個能做決定的人。資深工程師在真實專案裡也是這樣：拿不到完整資訊，就釐清狀況、選方向、溝通取捨、有新資訊再調整。

推理因為選了簡單起點會有被當成資淺的風險，作者接著說第三步——清楚解釋取捨，並稱這是強回答的核心。他給的關鍵鬆綁是：你不需要假裝自己的選擇是完美的，事實上不假裝通常更好。他甚至把句型直接寫出來：這是我會開始的方案、我認為它為什麼符合目前的需求、我接受哪些取捨、以及我在什麼情況下會回頭重新檢視這個設計。作者比較這個回答與另一種——列出五個可能方案然後等面試官告訴你哪個對——並說前者強得多，因為你聽起來像個能做決定的人。他在這裡把面試接回真實工作：那正是資深工程師在真實專案裡需要做的事，他們也拿不到完整資訊，必須釐清狀況、選一個方向、溝通取捨、在新資訊出現時調整。

• PExplain：用四句話講取捨，聽起來像個能做決定的人，而不是列五個方案等面試官挑→ 練習
• Ctwo-way door decision：附上撤回條件的決定是可逆的，可逆的就快速選，不可逆的才慢下來比較→ 畫地圖
• A四句話回答句型就是口說版的 ADR→ 批判類比
• R前端架構決定哪些可逆、哪些不可逆→ 存＋回想

AI 補充值得指出作者那個句型的第四句「什麼情況下我會回頭重新檢視」為什麼特別關鍵：它把一個決定變成有觸發條件的決定，於是「我可能選錯」不再是弱點，而是已經被納入計畫的一部分。這正好解掉第 2 段那個分析癱瘓——你之所以不敢選，是因為把決定當成不可撤回的；一旦附上撤回條件，決定的心理成本就大幅下降。實務上這也是決策紀錄（ADR）在做的事：寫下當時的情境、選了什麼、放棄了什麼、以及什麼會讓我們改變主意。另外可以補一個判準幫你判斷該花多少時間在一個決定上：這個決定是可逆的（換分頁策略、換狀態管理函式庫）還是幾乎不可逆的（資料模型、跨團隊 API 契約）？可逆的就快速選、先做再說；不可逆的才值得慢下來仔細比較。作者說的「先選一個合理起點」隱含的正是——大部分前端架構決定其實是可逆的。

術語:Architecture Decision Recorditwo-way door decisioni

8. 總結：把模式用在情境裡 10:06–11:07

所以前端系統設計面試即使有點人工，仍然有用：好的題目測的不是你知不知道某個模式，而是你能不能在情境中套用它。分頁不只是 offset 對 cursor，而是產品體驗與使用者如何在資料中移動；即時協作不只是 WebSocket 或 CRDT，而是互動模式、衝突模型，以及這個產品真正需要多少複雜度。最後作者宣傳頻道與他的前端系統設計課程。

推理因為前三步已經完整交代了做法，作者最後回頭替面試這個形式辯護：即使它有時候感覺很人工，仍然有用，因為好的題目測的不是你知不知道某個模式，而是你能不能在情境中套用它。他用兩個例子各回收一次來證明：分頁不只是 offset 對 cursor，而是關於產品體驗、以及使用者如何在資料中移動；即時協作不只是 WebSocket 或 CRDT，而是關於互動模式、衝突模型、以及這個產品實際上需要多少複雜度。最後他說明頻道之後會持續做前端系統設計、真實架構、以及如何像資深工程師那樣解釋決策的內容，並介紹他的前端系統設計課程。

• P把技術名詞翻譯成產品問題：不用記架構，也能推出架構→ 練習
• E好題目測的不是你認不認得某個模式，而是能不能在情境中套用它→ 存＋演練

AI 補充把整支影片倒過來看會發現它其實只講了一件事的兩面：「答案取決於情境」是診斷，「Clarify → Choose → Explain」是處方，而兩個例子是連接兩者的證據。真正可以帶走的，是那個把技術名詞翻譯成產品問題的習慣——遇到 offset 對 cursor，先問「資料會不會在使用者瀏覽期間變動、他需不需要回到特定位置」；遇到 WebSocket 對輪詢，先問「使用者能容忍多久的延遲」；遇到 CRDT 對後寫覆蓋，先問「兩個人多常撞到同一個東西、撞到的代價多大」。這些問題不需要記憶任何架構，卻能推出架構。最後值得補一句作者只暗示而沒有說破的話：這套方法之所以在面試裡有效，正是因為它在真實工作裡有效——面試官想確認的其實是明天把你放進專案，你會不會在資訊不足時把事情推動起來。