前端系統設計面試：用心智模型把一個 client-server 架構逐層加壓到微前端

1. 別背題目，要學心智模型 0:00–0:58

作者先否定「背 Spotify、Instagram 怎麼做」這類準備法，主張前端系統設計面試該練的是可遷移的心智模型i。他預告全片會走過 web performance、前端可擴展性、無障礙、大型狀態建模、SSR 與邊緣運算，並用一條主線把架構從最基本的 client-server 一路加壓到 scale leveli 7（微前端、微服務、負載平衡、CDN、design system）。

推理因為題目會換而模型不會換，所以作者把整支影片的目標訂成「交給你一組可遷移的心智模型」，並先攤開路線圖：web performance、前端可擴展性、無障礙、大型狀態建模、SSR、邊緣運算，最後用一條 scale level 的階梯把這些東西串起來，從最陽春的 client-server 一路加到微前端、微服務、負載平衡、CDN、design system。

• R別背「Spotify 怎麼做」：題目每次換、心智模型不換，要展示的是被需求逼出架構的過程→ 存＋回想

AI 補充這個開場其實已經預告了全片的敘事結構：不是「介紹七個技術」，而是「同一個系統被加壓七次」。畫面上的 scale level 卡片是階梯的第一階，之後每加一個非功能需求，畫面就會回到同一張架構圖再長出一塊。要留意的是這套 level 編號是作者自創的教學工具，不是業界標準，面試時可以借用它的順序來組織回答，但不必背編號。另外作者說的是「用在任何面試」，實際上這條線也直接對應真實專案的演進順序——多數團隊都是先有 client-server，再被效能與人數逼著往上加。

2. 功能與非功能需求（飛機比喻） 0:58–2:50

面試通常以一句很空的「來蓋 Instagram」開場，第一步是把它拆成需求。作者用飛機比喻分兩類：功能需求i是飛機要有的座位、起落架、引擎，也就是它要完成什麼；非功能需求i是航程、油耗、碳排、落地噪音，也就是它怎麼做到。對應到前端，功能需求由使用者看得到、摸得到的 UI 滿足，非功能需求則是效能、可擴展性、安全性。

推理因為要讓「需求」這個抽象詞可操作，所以作者換成飛機當載體：座位數、起落架、引擎、機身結構是功能需求，也就是這架飛機「要做到什麼」；航程、平均油耗、碳排、落地噪音是非功能需求，也就是它「怎麼做到」。接著他把比喻收回前端：功能需求由使用者看得到、摸得到的 UI 滿足，非功能需求則落在效能、可擴展性、安全性這些看不見的地方。

• Cnon-functional requirement：系統以什麼品質做到（多快、撐多少人、多安全），會產出架構；幾乎都可量化→ 畫地圖
• A飛機比喻：座位數、引擎是功能需求；航程、油耗、噪音是非功能需求→ 批判類比

AI 補充這個切法之所以重要，是因為它決定了面試前半場與後半場的分工：功能需求會產出畫面與資料結構，非功能需求會產出架構。很多人卡住是因為把兩者混著談——一邊畫 UI 一邊講 CDN，結果兩邊都講不深。飛機比喻還藏了一個好用的檢查：非功能需求幾乎都可以被量化（航程幾公里、油耗幾公升），所以當你講不出數字時，通常代表你把它當成形容詞在講（「要很快」），而不是當成需求在談。

3. 從使用者故事到低保真草稿 2:50–4:16

作者以 amazon.com 的商品列表頁當範例，把功能需求寫成使用者故事i：瀏覽商品、加入購物車、評分評論、線上下單付款。從這些故事就能導出第一版 UI，也就是低保真 mockup；有些面試會直接給你，有些要你自己畫。這張草稿是後面抽狀態、設計 API 的唯一依據。

推理因為功能需求要落地成畫面，所以作者選 amazon.com 的商品列表頁當範例，先把功能需求寫成幾條使用者故事——瀏覽商品、加入購物車、評分與評論、線上下單付款——再從這些故事畫出第一版低保真 mockup。他也提醒：有些面試會直接給你這張圖，有些要你自己畫。

• P從一句題目到低保真草稿：鎖定一個頁面 → 寫 user story → 畫只有區塊的草圖當共用座標系→ 練習

AI 補充選商品列表頁不是隨手挑的，作者後面會用數據證明它是流量最集中的頁面；先鎖定一個頁面，是為了讓後續每個決策都有具體對象可以指。另一個值得學的動作是「低保真」三個字：面試中畫得越精緻越浪費時間，草稿只需要能讓你指著某一塊說「這裡需要一個狀態」。這張圖在後面會被反覆使用——抽狀態指它、算讀寫比例指它、切微前端也指它——所以它其實是整場面試的共用座標系。

術語:low-fidelity mockupi

4. 抽狀態與不可再簡測試 4:16–6:11

狀態i要越少越好，因為狀態佔記憶體又會觸發 re-render。從 mockup 逐塊掃出需要的狀態：品牌清單的 loading/error/data、使用者選的品牌、購物車、分頁、商品列表的 loading/error/data。抽完後跑「不可再簡測試i」——試著拿掉任一個狀態變數，若 UI 就做不出來，才確定它是必要狀態。接著把它們落成實際資料結構：狀態原始值（selected brand、current page）與領域實體i（product、product brand）。

推理因為狀態既佔記憶體又會觸發 re-render，作者先立下「越少越好」的原則，再帶著這個原則逐塊掃過草稿：品牌清單要從後端抓，於是有 loading / error / data；使用者要勾選品牌，是使用者互動造成的狀態；購物車、分頁同理；商品列表本身又是一組 loading / error / data。抽完後他加了一道驗收動作——不可再簡測試——逐一嘗試拿掉每個狀態變數，若 UI 仍能運作，那個狀態就不是必要的。最後把結果落成兩類資料：狀態原始值（selected brand 是字串或字串陣列、current page 是數字）與領域實體（product、product brand）。

• Cstate：為畫出目前畫面必須記住的最小資訊；來源只有 data fetching 與 user interaction 兩種→ 畫地圖
• Pirreducibility test：逐一拿掉每個狀態變數，UI 還做得出來就砍掉→ 練習
• E最常見錯誤：把篩選後的商品陣列另存一份，它其實是商品陣列 + 選中品牌的推導結果→ 存＋演練

AI 補充畫面上那張圖把每個箭頭標成 Data Fetching 或 User Interaction，這其實是一個實用的分類法：狀態的來源只有兩種——外部資料進來，或使用者動作進來。用這兩個標籤掃過畫面，比憑感覺列狀態更不容易漏。不可再簡測試看起來像形式，實際上它擋掉的是最常見的錯誤：把「可以算出來的東西」存成狀態（例如把篩選後的商品陣列另存一份，而它其實是商品陣列加上選中品牌的推導結果）。作者也示範了面試裡合法的減負動作——他直接宣告購物車狀態超出範圍——這在真實面試中通常會被接受，但要主動說出口，而不是默默略過。

5. 狀態的高度：lifting state 6:11–9:02

狀態有三種高度：local、shared local、global，複雜的轉換各自可再套 reducer patterni。元件樹i是倒著長的，使用者看到的是最底層的葉子，所以狀態應該放在真正用到它的最底層，能不往上抬就不抬。原則是「as low as possible, as high as necessary」。回到範例，current page 要拿去打 API，得抬到與商品資料請求同層；品牌篩選也會影響同一個請求，於是三者都被抬成同層的 shared local state。

推理因為要談位置，作者先把位置變成三個刻度：local、shared local、global，並補一句每一層都可以在轉換複雜時套用 reducer pattern。接著他用一個反直覺的圖說明元件樹是倒著長的——使用者看到的是最底部的葉子——所以狀態應該從最底層開始放，能不抬就不抬，原則是「as low as possible, as high as necessary」。回到範例，current page 必須拿去打 API，所以要抬到與商品資料請求同層；品牌篩選也會影響同一個請求，於是三個狀態最後都被抬成同層的 shared local state。

• Clifting state：狀態被抬高不是因為很多元件要用，而是它成了某個副作用（API 請求）的輸入→ 畫地圖
• R三個刻度 local / shared local / global；原則「as low as possible, as high as necessary」→ 存＋回想
• Ecurrent page 與 brand filter 都要打同一支商品 API，所以被抬到與商品請求同層→ 存＋演練

AI 補充這裡有一個容易被略過的因果：狀態被抬高不是因為「很多元件想用」，而是因為它成了某個副作用（這裡是 API 請求）的輸入。找到那個副作用發生的位置，狀態的高度就確定了，不必憑感覺猜。另外作者只說了 global statei 的例子是驗證資訊，沒說的是抬高的代價——每次改變會讓整個子樹重算，這正是第 4 段講的「狀態會觸發 re-render」在架構層的回音，也是為什麼要用 as low as possible 當預設。至於這段結尾那句「先讓狀態很 global 再往上抬」，方向與他整段的主張相反，實際做法是相反的：從最低層開始，只在必要時往上。

術語:lifting statei

6. REST 建模與 under-fetching 9:02–13:26

把狀態翻成後端 API：先用 RESTi 觀點看待 product、product brand 這些實體。細看會發現單一 product 實體撐不住——價格常變、評分由評論算出、送達時間隨地址重算——於是一個實體被拆成五個，各自有自己的 REST endpointi，篩選與分頁一律用 query parameteri 掛在同一個 endpoint 上。代價是：一次頁面瀏覽至少要打五支後端 API，這就是 REST 的 under-fetchingi。到這裡功能需求已能被最陽春的 client-server 架構滿足，但它撐不住規模。

推理因為狀態要翻成後端契約，作者先用 REST 的眼光看待前面抽出的實體，把 product 展開成 price、name、description、rating、category、deliveryTime。展開後問題就浮出來：價格會頻繁變動且有幣別、評分是由評論算出來的、送達時間隨使用者地址即時重算——這三個都不該壓在 product 這一層。於是一個實體被拆成五個，各自有自己的 endpoint，而篩選與分頁不另開端點，一律用 query parameter 掛在原本的資源上。最後他把代價點名：一次前端頁面瀏覽至少要打五支後端 API，這就是 under-fetching，並宣告最陽春的 client-server 架構到此為止。

• Cunder-fetching：REST 資源切得越乾淨，一個畫面要組的資源越多；一次瀏覽打五支是 client-server 極限→ 畫地圖
• R拆實體判準：欄位的變動頻率、生命週期、計算來源跟主體不一樣就拆出去→ 存＋回想

AI 補充拆實體的判準值得單獨記住：不是「欄位多不多」，而是「這個欄位的變動頻率、生命週期、計算來源和主體一不一樣」。價格會單獨改、評分是聚合結果、到貨時間依賴另一個輸入（地址），三者都不屬於 product 自己的生命週期，所以各自獨立。這條判準在後端叫聚合邊界，在前端則直接決定你要打幾支 API、能不能分別快取，後面談快取策略時會再用到同一組資訊。要注意 under-fetching 是 REST 資源導向的必然結果而不是設計失誤：資源分得越乾淨，一個畫面要組的資源就越多。作者在這裡刻意讓 REST 撞牆，是因為它是後面 BFF 與 GraphQL 的動機來源。

術語:client-server architecturei

7. 六大非功能需求與該問的問題 13:26–15:52

非功能需求關心使用者分布、裝置、法規、以及變更成本。作者收斂成六項：web performance、client scalabilityi、availability/fault tolerancei、web accessibility（A/AA/AAA）、maintainabilityi、web security。他強調資深度不只看你答什麼，更看你問什麼，並示範一串好問題：預期流量多少、有無時段或地理的分布差異、有無 Prime Day 這種尖峰、使用者主要用什麼瀏覽器與裝置、載入速度是否關鍵、無障礙有無法規要求、有無特殊資安考量。

推理因為非功能需求太發散，作者先框出它們關心什麼——使用者是誰、分布在哪、用什麼裝置、有無法規、以及變更成本——再收斂成六項：web performance、client scalability、availability 與 fault tolerance、web accessibility、maintainability、web security。接著他轉了一個彎：資深度不只由答案決定，也由你問的問題決定，於是給出一串可以直接背的提問——預期多少流量、有無時段或地理分布差異、有無 Prime Day 這種尖峰、主要瀏覽器與裝置是什麼、載入速度是否關鍵、無障礙有無法規要求、有無特殊資安顧慮。

• R六大非功能需求，順序即後半段章節目錄→ 存＋回想
• P資深度也由你問的問題決定：每個問題都要夾住一個後面的決策→ 練習

AI 補充這六項不是隨意排序的，它們正好是本片後半段的章節目錄，而且順序有意義：效能與可擴展性先談，因為它們會改變架構圖；可維護性接在後面，因為它改變的是團隊與 repo；無障礙與資安放最後，因為它們主要靠實作紀律而不是拓撲。至於那串提問，真正的價值不在禮貌，而在於每個問題都會夾住一個後面要做的決策——問裝置是為了決定 bundle 預算與圖片尺寸，問尖峰是為了決定要不要為峰值容量付錢，問法規是為了決定無障礙要做到哪一級。作者提到無障礙的等級時把 A / AA / AAA 唸得含糊，記住三級即可：A 是最低、AA 是多數法規要求的水準、AAA 最嚴格。

8. 流量估算：back of the envelope 15:52–19:10

作者查出 amazon.com 每月來自美國約 21.1 億次造訪，東西岸分布平均，週二到週四為高峰、晚上 7 到 10 點是尖峰時段，7 成以上流量來自行動裝置。接著逐步收斂：月 21.1 億 → 週 5 億 → 週二到四 2.5 億 → 週四 1.25 億 → 尖峰小時 2100 萬次造訪，再乘上每次造訪平均 6.8 個頁面，得到尖峰每小時約 1.36 億次頁面瀏覽。重點不是數字精準，而是能把一個模糊的大數推到具體的每秒/每小時請求量。另外 59% 購買發生在行動裝置、70% 造訪落在商品搜尋頁，決定了後續最佳化的戰場。

推理因為「21.1 億」本身不能決定任何事，作者先補齊四項條件：來自美國的月造訪 21.1 億、地理分布平均、週二到週四為高峰且晚上七到十點是尖峰、行動裝置佔七成以上。接著逐步收斂：月 21.1 億 → 週 5 億 → 週二至四 2.5 億 → 週四 1.25 億 → 尖峰小時 2100 萬次造訪；再乘上每次造訪平均 6.8 個頁面，得到尖峰每小時約 1.36 億次頁面瀏覽。他強調重點不是算得準，而是能把模糊大數推到具體的每小時／每秒請求量，並在推導中和面試官一起講清楚每一步的假設。最後兩個數字定了戰場：59% 的購買發生在行動裝置、70% 的造訪落在商品搜尋頁。

• Pback of the envelope：每一步都是「總量 × 一個佔比」，佔比來自前面問出的分布→ 練習
• E美國月 21.1 億次造訪 → 尖峰每小時 1.36 億次頁面瀏覽；59% 購買在行動、70% 造訪在搜尋頁→ 存＋演練

AI 補充這段的方法論比數字重要：每一步都是「總量 × 一個佔比」，而每個佔比都來自上一段問出來的問題。這也是為什麼提問要先做——沒有那些分布資訊，你只能停在月造訪數，推不出尖峰。值得補的是這個推導刻意保守：它假設週內與時段的集中度只有 50%，實際電商的尖峰集中度通常更高，而 Prime Day 這類事件作者直接排除在外，因為為峰值容量長期付費是另一個成本決策。行動佔比則同時決定了兩件事——JavaScript 要輕（CPU 弱）、圖片可以更小（螢幕窄），後者反而是可以拿來占便宜的地方。

術語:back of the envelope calculationidimensional analysisi

9. Core Web Vitals 與 UI 動靜光譜 19:10–21:34

前端系統設計與後端最大的差別，是第一順位話題是 web performance，而它只有兩件事：載入多快、回應輸入多快。量化方式是 Core Web Vitalsi，作為前端的 SLIi（service level indicator）：LCPi 與 CLSi 管初次載入，INPi 管重新渲染與互動回應。接著作者提出關鍵提問——你的 UI 有多靜態或多動態？從媒體/部落格（極靜）、電商（靜中帶動）、社群（大量互動）到企業 SaaS 與 Uber（極動），不同位置決定了要用哪種最佳化手段。

推理因為前端與後端系統設計的第一順位不同，作者先把 web performance 推到最前面，並把它拆成兩件事：載入多快、回應輸入多快。為了讓它可討論，他引入 Core Web Vitals 當作前端的 SLI——LCP 與 CLS 管初次載入，INP 管互動回應。接著他丟出決定後續路線的提問：你的 UI 有多靜態或多動態？並畫出一條光譜，從媒體與部落格（幾乎全靜態）、電商（內容多但互動也多）、社群（大量使用者產生內容與即時互動），一路到企業 SaaS 與 Uber（狀態極多、內容極少）。

• CCore Web Vitals 是前端的 SLI：LCP / CLS 管初次載入，INP 管互動；還要一條目標線才算 SLO→ 畫地圖
• RUI 動靜光譜：靜態端靠複製資產（CDN），動態端靠移動運算（SSR / edge），電商在中間兩套都做→ 存＋回想

AI 補充這條光譜是全片的分岔點：靜態那端靠複製資產解決（下一段的 CDN），動態那端靠移動運算解決（SSR 與邊緣運算），而電商剛好卡在中間，所以兩套都得做——這正是作者選 Amazon 當例子的理由。另外要分清 SLI 和 SLO 的差別：Core Web Vitals 是指標本身（量出多少），你還需要一條目標線（例如 LCP 的 p75 要在 2.5 秒內）才構成目標。也要注意這些指標是以真實使用者的分布來看的，用自己的筆電量出來的數字通常過於樂觀，要靠真實使用者端的監控才補得上這一塊。

10. 網路延遲與 CDN（scale level 1） 21:34–24:28

先算物理極限：光纖中光速約每秒 30 萬公里，舊金山到紐約單程約 9 毫秒，人類感知「慢」的門檻是 100 毫秒，看似綽綽有餘。但實際封包要在多個交換節點間轉手，一次來回要 140–160 毫秒；TCP 建連要三次來回，加上 TLSi 的 HTTPS 至少四次，光是建立連線就約 600 毫秒。消除這段延遲最簡單的方法是把靜態資產複製到離使用者最近的 edge locationi，這就是 CDNi，也就是 scale level 1：client + server + CDN。

推理因為要證明延遲不是程式寫得爛，作者從基礎設施算起：光纖裡光速約每秒 30 萬公里，舊金山到紐約約 2654 公里，單程約 9 毫秒，而人要覺得慢得超過 100 毫秒——看起來完全不是問題。接著他戳破這個樂觀：封包不會直線飛，要在一連串交換節點間轉手，一次來回實測約 140 到 160 毫秒；再加上 TCP 建連與 TLS 交握的來回次數，光是把連線建起來就要好幾百毫秒。既然延遲來自距離，最直接的解法就是把靜態資產複製到離使用者最近的節點，也就是 CDN，於是架構長到 Level 1：client + CDN + server。

• CCDN：延遲 = 來回次數 × 地理距離，把靜態資產複製到 edge location 是唯一能同時砍每次來回的手段→ 畫地圖
• ESF→NY 光速單程 9ms，實測來回 140–160ms，再加 TCP + TLS 建連要好幾百 ms→ 存＋演練

AI 補充這段真正要教的是一個推理姿勢：先算物理下限，再看實際值差多少，差距就是可最佳化的空間。作者的具體數字要打點折——TCP 建立連線是一次來回（SYN、SYN-ACK 之後就能送資料），而 TLS 1.3 把交握壓到一次來回、續連甚至可以 0-RTT，所以現代 HTTPS 大約是兩次來回而不是四次；若走 HTTP/3（QUIC），TCP 與 TLS 的交握還會合併。但這不影響結論：來回次數乘上地理距離就是你付不起的成本，而縮短距離是唯一能同時砍掉每一次來回的手段。也要注意 CDN 在這一階只解靜態資產，動態路徑仍然要回源站，這個缺口是下一段的起點。

術語:network latencyi

11. 從白畫面到邊緣運算（scale level 3） 24:28–29:16

動態內容用 React/Vue/Angular 這類框架時，使用者先拿到空 HTML，下載 JS、初次渲染、抓資料、再渲染，中間就是白畫面i。SSR 讓伺服器先取資料並預渲染 HTML，使用者立刻看到內容，再靠 rehydrate 補上互動性。但 SSR 又把延遲問題請回來了——每次動態路徑都要回伺服器。於是把渲染搬到 edge functions（跑 Node 之類的執行環境、部署在離使用者近的節點），再把資料庫的唯讀副本i也推到邊緣，靜態資產、運算、資料三者都貼近使用者。代價由 CAP 定理i說明：既然要 partition tolerance，就得在一致性上讓步，唯讀副本同步有延遲；金融不能接受，社群可以。這就是 scale level 3。

推理因為動態畫面需要框架來管狀態與互動，作者先把純客戶端渲染i的成本攤開：使用者拿到的是一份幾乎空的 HTML，只有一個掛載用的 div，接著下載 JavaScript、初次渲染、抓資料、再渲染，中間就是白畫面，使用者可能以為網站壞了而離開。第一層解法是 SSR：伺服器先取資料、預先渲染好 HTML 送出，使用者立刻看到內容，再由 hydrationi 把互動補上。但 SSR 又把上一段的延遲問題請回來了，因為每個動態路徑都要回源站。第二層解法是把渲染搬到邊緣函式——同樣的程式碼部署在離使用者近的節點。可是邊緣函式仍要回中央資料庫取資料，於是第三層是把資料庫的唯讀副本也推到邊緣。三樣東西（資產、運算、資料）都貼近使用者後，作者用 CAP 定理標出代價：副本同步有延遲，資料可能不是最新的，金融場景不能接受，社群場景可以。這一整套就是 Level 3。

• Cserver-side rendering：伺服器先取資料渲染好 HTML，解 CSR 白畫面；hydration 前看得到按不動→ 畫地圖
• ALevel 1 到 3 是同一招用三次：把資產、渲染、資料依序搬近使用者，每次看「還剩哪段路最長」→ 批判類比
• RCAP 的正確講法：網路分區發生時，一致性與可用性只能挑一個；唯讀副本選可用性、換來最終一致→ 存＋回想

AI 補充這一段其實是同一招用了三次：把東西搬近使用者。理解它的關鍵是看每一次搬完之後「還剩哪一段距離沒被解決」——搬完資產剩渲染，搬完渲染剩取資料，搬完資料才收斂。這個「找出剩下那段最長的路」的習慣，比記住 SSR 或 edge function 的定義更有用。要補的是 hydration 的代價：預渲染的 HTML 讓使用者「看得到」，但在 JavaScript 下載並接手之前是「按不動」的，這段空窗會直接反映在第 9 段的 INP 上，也是後來 streaming SSR、islands、React Server Components 這些做法想縮短的部分。至於 CAP，影片的表述繞了一圈，正確的說法是：網路分區發生時，你只能在一致性與可用性之間挑一個；唯讀副本這個設計選的是可用性，換來的是最終一致性。

術語:server-side renderingiedge computingi

12. 用快取消除請求 29:16–31:40

可擴展性是「使用者變多而效能不掉、最好連程式都不用改」。作者主張最好的擴展手段是先消除請求，判準是問「哪些資料讀遠多於寫」。商品圖片與標題讀很多寫很少，適合快取；價格與到貨時間則讀寫都頻繁，不適合。CDN 本身就實作了 HTTP 快取i，越不常變的資產可以設越積極的快取策略；此外 CDN 還順手做資產最佳化i——壓縮通常省下約 25% 傳輸量、圖片轉成 WebP、甚至 JS minificationi。

推理因為可擴展性的定義是「使用者變多而效能不掉、最好連程式都不用改」，作者主張最有效的擴展是先消除請求，而判斷哪些請求可以消除的問題只有一個：哪些資料讀遠多於寫？回到商品列表頁逐塊看——商品圖片與標題被讀上百萬次卻很少變動，適合快取；價格與到貨時間則讀寫都頻繁，不能這樣處理。接著他指出 CDN 本身就實作了 HTTP 快取，資產送到客戶端時就帶著保存指示，越不常變的東西可以設越積極的策略。他順帶補上 CDN 的另一項紅利：資產最佳化——壓縮通常省下約 25% 傳輸量、圖片轉成 WebP、甚至做 JS minification。

• R判斷哪些請求可以消除只問一題：哪些資料讀遠多於寫？圖片標題可快取，價格到貨時間不行→ 存＋回想

AI 補充「讀寫比」這個判準其實是第 6 段拆實體那條判準的回音：當時把價格、評分、到貨時間從 product 拆出去，理由是它們的變動頻率不同；現在同一份資訊直接決定了誰可以被快取多久。這說明資料建模不是純學術動作，它會一路影響到快取策略與請求量。要補的是快取真正的難題不在設定，而在失效：積極的策略讓過期資料活得更久，所以實務上會把「內容變了就換檔名」（雜湊檔名＋長期快取）當成預設，而不是靠縮短快取時間。壓縮那個 25% 也視內容而定——文字類資產壓縮率遠高於此，已經壓過的圖片則幾乎壓不動。

13. API Gateway 與 BFF 31:40–34:34

壓力全落在伺服器上，而後端多半已切成微服務i。第一步加 API Gatewayi：它是反向代理i，把 HTTPS、快取、授權這類重複工作集中做一次，對內轉成 HTTP 讓服務間通訊更快。第二步加 BFF（backend for frontendi）：一個由前端團隊擁有的中介層，按畫面需要的形狀組資料，背後去打各微服務，等於實作 facade patterni。好處是前端不必等微服務排期就能出功能，還能一個 client 一個 BFF（桌機一個、行動一個），這也是前端工程師被期待要有全端知識的原因。

推理因為畫面上每個區塊都要向不同的微服務要資料，作者先加一層 API Gateway：它是反向代理，把 HTTPS、快取、授權這類每個服務都要做的重複工作集中做一次，對內轉成一般 HTTP，讓服務之間的通訊更輕。接著他加第二層 BFF：一個按畫面需要的形狀來組資料的中介層，前端只跟它說「這個畫面要這些東西」，由它去打各個微服務再拼起來，也就是 facade pattern。BFF 的關鍵不在技術而在歸屬——它由前端團隊擁有，所以出功能不必等微服務排期；而且可以一個 client 一套（桌機 BFF、行動 BFF），互不干擾。作者順勢點出這就是前端工程師被期待要有全端知識的原因。

• Cbackend for frontend：按畫面形狀組資料的 facade，由前端團隊擁有，一個 client 一套→ 畫地圖
• RAPI Gateway 解「重複實作」（HTTPS、快取、授權做一次），BFF 解「形狀不匹配」（領域切 vs 視圖切）→ 存＋回想

AI 補充這兩層常被混為一談，但它們解的問題不同：API Gateway 解的是橫切關注點（每個服務都要做的事只做一次），BFF 解的是形狀不匹配（後端按領域切、畫面按視圖切）。判斷你需要哪一個，就看你的痛點是「重複實作」還是「前端要打很多支再拼」。BFF 的代價也值得先想清楚：它是一個必須部署、監控、擴展的服務，且每多一個 client 就多一份要維護的程式；當畫面差異不大時，一個 BFF 加參數往往比兩個 BFF 划算。另外 BFF 由前端團隊擁有這件事，其實已經是下一個章節（可維護性與康威定律）的伏筆——它是用組織邊界來換交付速度。

14. GraphQL 與水平擴展（scale level 4） 34:34–36:58

在 BFF 上加 GraphQLi，就能用一次查詢取多個資源，直接解掉開頭那個 under-fetching：原本一次瀏覽五支 API，現在變成一次查詢，由 BFF 的 resolveri 分頭去取再組成單一 JSON。附帶好處是前端能只要它需要的欄位，對流量敏感的行動使用者特別有利。流量現在集中在 BFF，所以用水平擴展i：加負載平衡器i，依 round robini 或最少連線數把流量分給多個相同實例。這就是 scale level 4。

推理因為 BFF 已經是「按畫面組資料」的位置，作者在它上面加 GraphQL：前端用一次查詢就取到多個資源，由 BFF 的 resolver 分頭去打各微服務再組成單一 JSON 回傳，原本一次瀏覽五支 API 變成一次查詢。附帶的好處是前端可以只要它需要的欄位，不多不少，對流量敏感的行動使用者特別有價值。至於流量集中在 BFF 的問題，他用最直接的水平擴展處理：加一台負載平衡器，依 round robin 或最少活躍連線數把流量分給多個相同的 BFF 實例。這一套就是 Level 4。

• CGraphQL：一次查詢取多個資源、只要需要的欄位；解的是「形狀」不是「速度」，後端服務一支都沒少→ 畫地圖
• R面試提 GraphQL 要主動說代價：查詢複雜度要限制、快取比 REST 難→ 存＋回想

AI 補充GraphQL 解的是「形狀」而不是「速度」——它把多次來回換成一次來回，但後端該打的服務一支都沒少，只是移到 BFF 內部並行處理。也因此它引進了自己的新問題：查詢複雜度需要限制（否則一個惡意查詢可以打爆後端）、快取比 REST 難（不再是一個 URL 對應一份資源，要靠正規化的客戶端快取或持久化查詢）。這些是面試中提到 GraphQL 時值得主動說出來的取捨。水平擴展這邊也有一個前提沒被說破：實例必須是無狀態的，同一個使用者的下一個請求才能被送到任何一台；session 一旦存在實例記憶體裡，加機器就會出錯。

術語:over-fetchingi

15. 康威定律與微前端（scale level 5） 36:58–39:24

可維護性是「擴充系統有多容易」。就算後端已微服務化，前端仍是單體，而康威定律i說組織設計出的系統會複製自己的溝通結構；團隊一大，溝通線就爆炸（3 人 3 條、14 人 91 條），作者舉了一個 45 人開 1.5 小時 daily standup 的真實案例。依貝佐斯的兩個披薩原則要拆團隊，而依康威定律，拆團隊就得拆系統：把前端單體拆成微前端i——各自獨立、各自網域、各自發版，由一個 shell 在執行期組起來給使用者看。這是 scale level 5。

推理因為可維護性談的是擴充系統的容易程度，作者先搬出康威定律：組織設計出的系統會複製自己的溝通結構。接著他把「團隊太大」量化成溝通線的數量——3 人 3 條、14 人 91 條，畫面上那張圖讓成長速度一目瞭然——並補上一個真實案例：某公司 45 人共用一個單體應用，每天開 1.5 小時的站立會議，九成內容與你無關。既然貝佐斯的兩個披薩原則說團隊該拆，而康威定律說系統會長成團隊的樣子，那要拆團隊就得先拆系統。於是前端單體被拆成微前端：各自獨立、部署在不同網域、各自發版，由一個 shell 在執行期把它們組起來呈現給使用者。這就是 Level 5。

• CConway's law：系統會複製組織的溝通結構；溝通線隨人數平方成長 → 拆團隊就得先拆系統 → 微前端→ 畫地圖
• E3 人 3 條溝通線、14 人 91 條；某公司 45 人共用單體，每天 1.5 小時站立會議九成與你無關→ 存＋演練

AI 補充這段的推理鏈值得單獨記：溝通成本隨人數呈平方成長 → 大團隊必然低效 → 拆團隊 → 依康威定律必須同時拆系統 → 微前端。倒過來看也成立，而且更常用：如果你的系統邊界和團隊邊界對不上，痛苦會出現在每次發版的協調上。微前端的代價作者沒展開，但面試中值得主動提：重複的相依套件會讓總下載量變大、跨應用的路由與狀態共享變複雜、樣式與版本容易失控。這也直接說明了為什麼下一段必須補兩樣東西——沒有那兩樣，微前端會退化成一堆看起來不像同一個網站的應用。

術語:two-pizza teamishell applicationi

16. Design system 與 monorepo 39:24–41:47

微前端拆開後產生兩個新問題。第一是視覺不一致：解法是 design systemi——一套內部共用的 UI 元件庫，通常以 npm 套件發佈，目標是加快開發（不必每個團隊重刻表單和日期選擇器）與跨微前端的視覺一致。第二是程式品質與人員流動：各自的 repo 會各有 lint 規則、TypeScript 設定、測試環境與套件版本，於是全部收進 monorepoi——共用建置系統、共用品質工具、共用套件，甚至共用部署流程（各應用產出 docker image 再由 monorepo 工具一起部署）。這是 scale level 7，擴展的是組織。

推理因為視覺一致性沒了，作者先補 design system：一套內部共用的 UI 元件庫，通常以 npm 套件發佈給所有微前端使用。它的兩個目的很明確——加快開發（不必每個團隊各自重刻表單、日期選擇器）與跨應用的視覺一致。第二個洞是程式品質與人員流動：各自的 repo 會各有 lint 規則、TypeScript 設定、測試環境與套件版本，於是他把所有應用收進同一個 monorepo，共用建置系統、共用品質工具、共用套件，甚至共用部署流程——各應用產出 docker image，再由 monorepo 的工具一起部署到各自的網域。附帶效果是透明度：任何人都能讀到公司幾乎所有原始碼。這一層他稱為 Level 7，擴展的對象是組織。

• Rdesign system 統一使用者看到的東西，monorepo 統一工程師碰到的東西——把微前端拆散的「該一致的部分」收回→ 存＋回想

AI 補充這兩樣東西要一起看，才看得出它們在補同一件事：微前端把系統拆開換取自主，而 design system 與 monorepo 把「該一致的部分」重新收攏，避免自主變成失控。分辨兩者的分工很有用——design system 統一的是使用者看到的東西，monorepo 統一的是工程師碰到的東西。實務上兩者都有代價：design system 需要專責維護，否則會變成沒人敢改的化石；monorepo 需要投資工具（受影響範圍偵測、遠端建置快取），否則 CI 時間會隨 repo 成長線性惡化。要注意的是這裡的 scale level 編號不連續（作者從 Level 5 直接跳到 Level 7），記順序就好。

17. 可用性、單點故障與 active-passive 41:47–43:42

可用性靠的是分布模式，而 CDN、負載平衡器、唯讀副本這些為了擴展而加的東西，同時也提高了可用性：任一 edge location、任一實例、任一副本掛掉都能把流量導去其他健康的節點。但負載平衡器與主資料庫本身變成單點故障i——一掛全系統倒（DNS 伺服器也是典型例子）。作者補了一個 active-passive 模式：兩台負載平衡器，一台接流量、一台待命，主的掛了立刻切過去。前端工程師不需要會實作，但要有這層心智模型。

推理因為可用性靠的是分布，作者先指出一個順帶的好消息：前面為了效能與擴展加進來的元件本來就有冗餘——CDN 的某個 edge location 掛了可以改導其他節點，負載平衡器後面的實例掛了可以只送給健康的，唯讀副本掛了還有其他副本。但接著他把壞消息點名：負載平衡器與主資料庫本身只有一份，它們是單點故障，DNS 伺服器也是同類。解法是他當作彩蛋補上的 active-passive 模式——放兩台負載平衡器，一台接流量、一台待命，主的失效就立刻切過去。他也提醒前端工程師不需要會實作，但要有這層心智模型。

• P可用性檢查：對著架構圖逐個元件問「這個只有一份嗎」，只有一份的就是天花板→ 練習

AI 補充這段的實用價值在於一個檢查動作：對著自己畫的架構圖，逐個元件問「這個只有一份嗎？」凡是只有一份的，就是可用性的天花板。要補的是 active-passive 不是免費的——待命那台平常閒置卻要付費，而且切換需要偵測失效與轉移流量（通常靠健康檢查加虛擬 IP 或 DNS 切換），這段空窗就是實際的停機時間。另一個常被忽略的是：待命節點必須被定期演練，否則真的要切的時候往往才發現它的設定早就過期了。

術語:active-passive patterni

18. 無障礙與資安速查 43:42–46:07

無障礙的做法：一切用語意化 HTMLi（h1、list、footer 這類），實在做不到才用 ariai 屬性，且應是例外不是常態；tab 順序要與畫面視覺順序一致；用 axe 這類外掛在開發階段就測。常見反例是 React 開發者習慣多包一層 div/span。資安則要能講清楚主要攻擊：中間人（用 HTTPS 加密）、XSSi（不要執行使用者給的內容，別用 dangerouslySetInnerHTML）、CSRFi（重要操作加二階段驗證）、SQL injectioni（後端用 ORM）、DDoSi（流量過濾、Cloudflare 這類大網路、rate limiting）。

推理因為無障礙的大部分收益來自預設值，作者的第一條就是盡量用語意化 HTML，這樣許多無障礙行為是免費的；真的做不到時才用 aria 屬性，而且應該是例外；tab 順序要與畫面的視覺順序一致（用語意化 HTML 通常自然成立）；最後在開發階段就用 axe 這類工具測，而不是上線後才補。他點名最常見的反例是 React 開發者習慣多包一層 div 或 span。資安部分他採速查表的形式，要求你能講清楚主要攻擊與對策：中間人（全站 HTTPS）、XSS（不要把使用者內容當程式執行，別用 dangerouslySetInnerHTML）、CSRF（重要操作加第二因素）、SQL injection（後端用 ORM）、DDoS（流量過濾、Cloudflare 這類大型網路、rate limiting）。他也回頭補了一句：CDN 的節點分布本身就讓攻擊者很難打垮系統。

• R無障礙四條：語意化 HTML 優先、ARIA 是例外、tab 順序等於視覺順序、開發期就用 axe 測→ 存＋回想
• R資安速查：MITM→HTTPS、XSS→不執行使用者內容+CSP、CSRF→SameSite+token、SQLi→ORM、DDoS→過濾+限流→ 存＋回想

AI 補充這兩份清單看起來像背誦題，但有一條共同邏輯值得抓住：預設安全比事後檢查便宜。語意化 HTML 是無障礙的預設值，ORM 的參數化查詢是 SQL injection 的預設值，框架預設跳脫輸出是 XSS 的預設值——這些做法之所以有效，是因為它們讓「做對」比「做錯」更省事。要補兩點：第一，CSRF 的標準對策其實是 SameSite cookie 與 CSRF token，第二因素只適合真正高風險的操作，對每個寫入請求都要求二次驗證並不可行；第二，XSS 的防線除了不執行使用者內容，還包括 Content Security Policy，它是在你不小心漏掉時擋下來的第二層。無障礙的等級（A / AA / AAA）在第 7 段已經提過，這裡的四條做法就是把 AA 拿下來的最短路徑。

術語:man-in-the-middle attacki

19. SEO 與前端可觀測性 46:07–48:25

兩個加分題。SEOi：前面做的事幾乎全都順便幫到 SEO——SSR 交給爬蟲預渲染好的 HTML、語意化 HTML 讓頁面對爬蟲有意義、Core Web Vitals 高 Google 排名更好。可觀測性i是團隊理解系統現況的能力：集中式的 log 與告警（Datadog）、真實使用者監控i看實際 Core Web Vitals（Sentry）、產品分析做功能決策與 A/B 測試（Amplitude）、網站分析看轉換漏斗（Google Analytics）、以及處理使用者資料必備的 consent manageri。最後把這些分析工具丟給 web workeri 執行，主執行緒才不會被拖慢。

推理因為前面的決策已經順帶解決了 SEO，作者只需要把連結指出來：SSR 交給爬蟲的是預先渲染好的 HTML，比空殼容易消化；語意化 HTML 讓頁面結構對爬蟲有意義；Core Web Vitals 高則直接影響 Google 排名。第二個加分題是可觀測性，也就是團隊理解系統現況的能力，他按用途分了五類工具：集中式的 log 與告警（Datadog）、真實使用者監控看實際的 Core Web Vitals（Sentry）、產品分析決定要擴充哪些功能與做 A/B 測試（Amplitude）、網站分析看廣告漏斗與轉換（Google Analytics）、以及處理使用者資料時必備的 consent manager。最後他補上一個效能上的收尾：把這些分析工具丟給 web worker 執行，主執行緒才不會被自己加的工具拖慢。

• R五類可觀測性工具各答一題：log 壞了嗎、RUM 多快、產品分析用什麼、網站分析從哪來、consent 有沒有權利收→ 存＋回想

AI 補充SEO 這段其實驗證了全片的核心主張——好的非功能需求決策會互相加成，而不是彼此交換。同一個 SSR 決定同時買到了首屏速度、可被爬蟲索引與更好的排名；同一個語意化 HTML 決定同時買到了無障礙與 SEO。這也是面試中把「順帶解決了什麼」講出來的價值所在。可觀測性那五類工具的分野值得記牢，因為它們回答的問題完全不同：log 回答「壞了嗎」，RUM 回答「使用者實際體驗多快」，產品分析回答「他們在用什麼」，網站分析回答「他們從哪來、有沒有轉換」，consent manager 回答「我們有沒有權利收這些」。最後那個 web worker 的提醒是全片最後一個閉環：第 9 段說 INP 量的是主執行緒被塞住的程度，而分析工具正是塞住它的常見元兇。