微服務面試題目

你讀過各種模式的名稱，也能背出斷路器的作用，卻還是抓不到面試官到底在聽什麼。這一節說明面試官實際評分的四個面向，依照他們通常探詢的順序排列。每一項看似在考詞彙，實際上考的是判斷力。

• 拆解方式。你會從哪裡切分，為什麼選在那裡？面試官希望邊界是沿著業務能力或資料所有權劃分，而不是按技術分層切。
• 通訊方式。同步請求／回應，還是非同步事件，各自會在什麼情況下出問題？他們要的答案是取捨分析，不是單純的偏好。
• 資料。每個服務各自一個資料庫，代表不能跨服務做 join，也沒有分散式交易。那要怎麼確保系統仍然正確？
• 維運。部署、版本管理、追蹤，以及當某個服務變慢而非直接掛掉時，凌晨三點該怎麼辦。

注意這些都與框架無關。能說清楚為什麼把結帳與庫存拆開的應試者，永遠會比只會列出註解標籤的人拿到更高分。

這些是大多數微服務面試回合開場常見的題目，底下附上面試官實際在檢驗什麼。

• 你會怎麼把這個單體架構拆成多個服務？檢驗你是沿著業務能力與資料所有權切分，還是照 controller、service、repository 這種分層切。後者切出來的仍是分散式單體。
• 兩個服務之間要怎麼溝通？檢驗你能不能說出每種選擇的代價：同步呼叫給你簡單的心智模型，但會把可用性綁在一起；非同步事件能解耦可用性，但要能跟產品負責人解釋最終一致性。
• 什麼是分散式單體，又要怎麼避免？檢驗你是否知道必須一起部署的服務，其實稱不上真正分開。
• 一個服務該多大？檢驗你不會被誘導講出一個數字。大小應該跟著邊界與擁有它的團隊走。
• 需要 API 閘道嗎？它的作用是什麼？檢驗你能不能把路由、身分驗證與流量限制從商業邏輯中分離出來。
• 服務之間要怎麼互相找到彼此？檢驗你對服務探索的基本掌握，以及為什麼寫死主機位址在規模化環境中行不通。

每個答案都要把取捨大聲說出來。面試官沒辦法為你只在腦中默默做過的比較給分。

面試真正的勝負關鍵就在這裡，因為這些問題沒有乾淨俐落的答案，應試者卻往往只想搬出背好的說法。

• 你要怎麼確保跨服務的資料一致性？先講清楚限制條件：沒有跨服務交易這回事。接著描述一個 saga，可以是透過事件編排，也可以是由協調者統籌，並且明確說出系統是最終一致的，以及使用者在這段落差期間會看到什麼。
• 下游服務變慢時會發生什麼事？逾時、帶退避的重試，以及斷路器，避免變慢的依賴耗盡你的執行緒池。變慢比直接掛掉更糟，能講出這點代表你有實戰經驗。
• 要怎麼讓重試是安全的？冪等性。在寫入路徑加上冪等鍵，讓重複送出的付款請求只會扣款一次。
• 多步驟流程中發生部分失敗時要怎麼處理？用補償動作，而不是回滾。說明退款或釋放預訂會是什麼樣子。
• 怎麼除錯一個經過六個服務的請求？用分散式追蹤，讓關聯 ID 一路傳遞到每一站，再搭配結構化日誌與指標。

一位應徵公有雲廠商 L5 平台職缺的後端工程師，被問到 saga 問題時一口氣答完，用的全是模式詞彙，卻完全沒提到客戶會看到什麼。真正決定這一輪成敗的追問，是訂單頁面在不一致的那段時間會顯示什麼。要準備的是第二個答案，而不只是第一個。

更多依角色與主題整理的題庫，收錄在依角色分類的面試問題。

讀完這份清單會讓你產生「我認得這個」的感覺，但這種感覺一旦換成陌生人開口發問、然後等你回答，就會瞬間消失。知道一個模式和在輕微壓力下把它講清楚之間的落差，正是系統設計面試最難的地方，而這個落差只能靠開口說話來補上。

挑一個你熟悉的流程，例如下單或註冊，然後大聲把完整的拆解過程講出來：邊界在哪、通訊方式怎麼選、一致性怎麼說、失敗情境怎麼說。一直練到你不再重講開頭的句子為止。你可以在模擬面試模式中，對著會追問、也能讓你用語音回答的 AI 面試官練習這些提示，這比重看筆記更接近真實情境。

SubcueAI 創辦人 Aaron Cao 打造這個練習模式時，關注的正是這個落差，而不是內容本身的呈現方式。題目清單到處都找得到，應試者真正缺的是在有人等待的情況下，反覆把答案講出來的練習。在真正的面試中，桌面應用程式與瀏覽器擴充功能的側邊欄可以在面試官說話時，同步顯示結構化的提示，不過練熟的說法永遠勝過第一次現讀的內容。這個助手會做什麼、不會做什麼，說明都在產品總覽頁面。