前情提要
整理一次技術面試的對話紀錄，主題圍繞在大流量電商系統的設計與應變。
面試公司：H 社，北台灣，科技服務業，員工數十人。實際業務為線上遊戲平台的開發與維運；產品涵蓋自研遊戲、第三方遊戲接入，以及面向代理商與玩家的平台系統。整體採微服務架構，開發部門數十人，小組制運作。跨國營運，技術端設於台灣。
職位：後端為主的全端工程師，技術棧含 Node.js / Go、現代前端框架、SQL / NoSQL，要求具備架構設計與 CI/CD 實務能力，並承擔技術指導職責。
以下按主題整理成 Q&A，並附上現代技術視角供參考。
大流量與快取架構
Q：電商搶購時流量瞬間暴增，怎麼擋？
先接受「讓使用者排隊，不讓網站 crash」這個前提，整個設計才會清楚。
具體做法是多層 Cache 疊加：
- 前端：搶購期間關掉非核心的資訊（推薦、廣告等），減少後端壓力
- 後端第一層：庫存資料放 Redis
- 後端第二層：使用 MemoryCache（.NET 4.5/4.6 內建）做本地快取
- DB 層：DB 自身的查詢快取
流量依序被每一層擋掉，真正打到 DB 的請求量才能控制住。
現代解法：Kubernetes + HPA（Horizontal Pod Autoscaler）根據 CPU / Memory 自動擴縮容，不再需要預先備機和人工值班。Redis 依然是標準選擇，但搭配 Lua Script 或 WATCH/MULTI/EXEC 可更精確控制庫存的原子操作，避免超賣。
Q：那時候沒有 Kubernetes，怎麼做水平擴充？
用 VM 搭配手動的負載分流。備用機平時待機，搶購前預先準備好；緊急時把流量導過去。
沒有自動 scale，所以需要人工值班監控——雙 11 期間三班制，值班加 on-call 全員待命。
現代解法：Kubernetes 的 Deployment + HPA 讓水平擴充自動化，節省人力成本。搭配 Cluster Autoscaler，甚至連底層節點都能自動增減，不再需要預先開好備用機等待。
監控與事故應對
Q：系統是 crash 了才知道，還是有提前預警？
有兩個觸發條件：
- 資源閾值警報：CPU 或 Memory 超過 80% 就通知，不等到崩潰
- 錯誤日誌頻率：同類型錯誤在短時間內高頻出現，自動告警
這些監控都是自己開發的，那個年代沒有現成的 APM 工具可以直接套。
現代解法：Prometheus + Grafana 是現在的標準配置，幾乎不需要自己開發。資源閾值警報用 AlertManager 設定即可；錯誤頻率則可搭配 ELK Stack 或 Loki，對 log 做 rate 統計觸發告警。SaaS 選項如 Datadog、New Relic 更是開箱即用。
Q：真的發生過事故嗎？當下怎麼處理？
有發生過，包含主機掛掉切備用機、備用機跟著掛掉的連環情況。
第一線的原則是：先讓系統回來，問題找根因可以之後再說。
當下操作是執行預先備好的備案（切流量、重啟服務），同時通報讓有能力解決根本問題的人起來處理。
事後改進：正式搶購活動前一定先壓測，模擬預估流量的 110%，只測核心購物流程，把能關的功能全部關掉。
現代解法：事故應對流程本身可以標準化為 Runbook，記錄每種已知情境的處置步驟，讓值班工程師不需要靠記憶應急。Kubernetes 搭配 liveness/readiness probe 可自動偵測服務不健康並重啟，減少人工介入的時間窗口。壓測工具如 k6 或 Locust 可整合進 CI/CD，讓每次上線前自動跑一輪基準測試。
金流系統設計
Q：對接多個金流廠商，程式碼怎麼不變成一團亂？
用 Strategy Pattern 的概念，把金流流程切成 Workflow。
整個下單流程是一條工作站鍊：
1 | 商品計算（折扣、贈品）→ 訂單建立 → 金流付款 |
金流工作站本身的邏輯很薄：根據使用者選的付款方式，決定走哪個 Strategy。不同廠商（信用卡、超商取貨、銀行轉帳）各自封裝成獨立模組，主流程不在意裡面怎麼串接。
新增金流廠商：加一個新模組，主流程不用改。
現代解法：這個架構今天依然適用，核心概念沒有過時。如果系統更大，可以把每個金流廠商拆成獨立的微服務，透過統一的 Payment Gateway API 對外暴露，主流程完全不感知廠商差異。設計模式上除了 Strategy，也可以考慮 Plugin Architecture，讓新廠商直接以套件形式掛入，不需要改動核心程式碼。
Q：訂單成立了，金流卻失敗，怎麼處理？
訂單成立和金流付款是兩個獨立的 Transaction。
金流失敗不會 rollback 訂單，而是讓訂單保持「待付款」狀態，通知使用者重新付款或換付款方式。
好處是：金流失敗是常見的可預期錯誤，這樣設計使用者體驗比較好，也避免訂單資料不一致。
現代解法：在微服務架構下，這個問題升級為分散式交易問題。現代標準解法是 Saga Pattern：每個步驟成功後發事件觸發下一步，失敗時執行 compensating transaction 回滾前面的狀態，整個流程不依賴跨服務的 ACID Transaction。Choreography Saga 適合步驟簡單的流程，Orchestration Saga 適合需要集中管控的複雜流程。
AI 與本地部署
Q：你做的法律 AI 系統，為什麼不用雲端大模型就好？
客戶是大型企業（Sony、政府機關、醫療機構），他們不願意把公司內部資料送上雲端。
做法是把 AI 系統打包進實體機器，送進客戶的內網部署。功能類似 ChatGPT，但跑在客戶自己的機房裡。
主要應用場景是：
- RAG：上傳法律文件，AI 從裡面查詢相關資訊
- 專利風險分析：原本需要半年人工查詢各大專利資料庫，自動化後大幅縮短
現代工具：本地部署 AI 的技術棧已經成熟許多。Ollama 可以一鍵跑主流開源模型（Llama 3、Mistral 等），LlamaIndex 或 LangChain 提供 RAG pipeline 的標準建構塊，向量資料庫用 ChromaDB、Qdrant 或 Weaviate 都可以，整個 stack 都可以打包進客戶內網。對於需要更強模型的場景，也可以考慮 vLLM 搭配企業級 GPU，在不上雲的前提下跑到生產等級的推論效能。
關於 AI 對開發的影響
Q：你覺得 AI 工具對軟體開發的影響是什麼？
一個工程師現在能產出的東西，可能相當於十年前一整個小團隊的產出。
但這也帶來新的問題：程式碼產出速度快了，但架構決策、程式碼品質的門檻反而更重要。AI 可以快速生出大量程式碼，但如果架構設計不對，技術債也會累積得更快。
進一步的觀察：Coding style 和命名規範這類問題，現在完全可以交給 AI 處理——把 guideline 寫好，讓 AI 執行和稽核就好，不值得花人力在上面爭論。真正需要人把關的是 Domain 層和 Use Case 層的設計：商業邏輯有沒有被正確封裝？Unit Test 有沒有覆蓋核心行為？這兩層做對了，架構就不容易爛掉。六邊形架構（Hexagonal Architecture）或 Clean Architecture 在 AI 輔助開發的時代反而更值得落地，因為邊界清楚，AI 才不容易在錯誤的地方塞邏輯。
面試反思
用業界術語包裝已知的答案
描述分散式交易的處理方式時，邏輯是對的，但沒有說出 Saga Pattern 這個詞。面試官如果熟悉這個詞，會更快建立信心；說不出來反而讓人以為是靠直覺摸索，不是系統性的設計知識。同樣的，提到 Request ID 追蹤時，可以直接說 Distributed Tracing、OpenTelemetry，展示對現代標準的認識。術語不是裝飾，它是讓對方快速理解你程度的捷徑。
主動帶出現代解法
談電商 N 社那個年代的做法時，可以補一句「現在我會用 Kubernetes + HPA 處理這個問題」——展示持續學習的態度。技術知識有，但沒有主動說出來，廣度就沒有完整呈現。
這兩點對應的技術題目值得另外整理成文章研究：Saga Pattern、Distributed Tracing、OpenTelemetry。
小結
- 大流量不靠單一技術解決，是多層 Cache + 系統開關 + 人工值班的組合
- 監控要在系統崩潰前就觸發，資源閾值和錯誤頻率是兩個實用的指標
- 事故處理分兩階段：先讓系統回來，再找根因
- 金流複雜性用 Strategy Pattern + Workflow 拆解，廠商細節封裝進模組
- 本地 AI 部署是企業安全性需求的實際解法，不只是技術選擇
(fin)