https://yennj12.js.org/yennj12_blog_V4/tags/bigquery/Recent content in BigQuery on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSat, 30 May 2026 11:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part4-system-design-zh/Sat, 30 May 2026 11:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part4-system-design-zh/System Design 是 FDE 面試最能展現工程深度的地方。 面試官不是要你「寫出可以跑的程式碼」， 他想看的是：你在有限資訊下，怎麼做設計決策、怎麼說清楚 trade-off。 面試情境 面試官：「請你設計一個供企業內部使用的 AI 知識庫問答系統，員工可以用自然語言查詢公司政策、產品說明和技術文件。第二題：設計一個 AI Copilot，讓員工用自然語言查詢公司內部數據，例如『今年 Q3 的營收比 Q2 成長了多少？』」 一、System Design 面試的本質 面試官考系統設計，不是要標準答案，是要看三件事： 考點 1：釐清問題的習慣 你有沒有在設計前先問問題？ → 不假設，先問。沒有釐清需求就開始畫圖是大扣分。 考點 2：Trade-off 思維 你說的不是「最好的方案」，而是： 「在這個場景下，我選 X 而不是 Y，因為...」 考點 3：生產環境的現實感 Auth、RBAC、Scale、Cost、Failure Mode—— 有沒有考慮到，是高手和普通人的分水嶺。 二、第一題：企業知識庫 Chatbot 步驟一：釐清需求（你要主動問） 你應該問的問題： 需求面： ├── 同時使用的用戶數量級？（100 人 vs 10 萬人，架構差很多） ├── 文件量多大？（1GB vs 1TB） ├── 回答需要引用文件來源嗎？ └── Latency 要求？（秒級 vs 毫秒級） 安全面（這是 FDE 常被忽略的）： ├── 不同部門能看的文件不同嗎？→ 決定要不要 RBAC ├── 有合規要求嗎？（GDPR、SOC 2） └── 資料能放在公有雲嗎？ 這些問題決定你的架構複雜度。 先問，再設計。 步驟二：完整系統架構 ┌─────────────────────────────────────────────────────────────┐ │ 用戶層 │ │ Browser / Slack Bot / Mobile App │ └───────────────────────────┬─────────────────────────────────┘ │ HTTPS ┌───────────────────────────▼─────────────────────────────────┐ │ API Gateway 層 │ │ ├── SSO Token 驗證（Google Workspace / Okta） │ │ ├── Rate Limiting（防止濫用） │ │ └── 請求日誌（Audit Log 起點） │ └───────────────────────────┬─────────────────────────────────┘ │ 已驗證的用戶 context ┌───────────────────────────▼─────────────────────────────────┐ │ Chatbot Service 層 │ │ │ │ ┌────────────────────┐ ┌─────────────────────────────┐ │ │ │ Query Processor │ │ RBAC Module │ │ │ │ ├── 意圖分類 │ │ 「這個用戶能看哪些文件？」 │ │ │ │ └── Query Rewrite │ │ 在查詢前過濾，不是查完再過濾 │ │ │ └────────────────────┘ └─────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ RAG Engine │ │ │ │ Query → Embedding → [Vector DB + RBAC Filter] │ │ │ │ → Reranker → Context Injection → LLM │ │ │ └──────────────────────────────────────────────────────┘ │ └───────────────────────────┬─────────────────────────────────┘ │ ┌───────────────┬───────────▼──────────┬──────────────────────┐ │ Cache Layer │ Response Generator │ Logging & Monitoring│ │ （相同問題） │ （加入引用來源） │ （審計 + 成本追蹤） │ └───────────────┴───────────────────────┴──────────────────────┘ 設計決策一：Authentication 的選型 選項比較： API Key JWT + SSO ──────────────────────────────────────────────────────── 適合場景 機器對機器 人類用戶登入 身分追蹤 無（共用 key） 有（每個 token 帶用戶身分） RBAC 支援 無（要額外設計） 原生（token payload 帶角色） Token 輪換 麻煩 自動（SSO refresh） 企業整合 困難 直接接 Google Workspace / Okta 結論：企業知識庫選 JWT + SSO token payload 帶 user_id、department、roles， 後面所有服務直接讀，不需要每次去查資料庫 面試官最想聽到的一句話：