https://yennj12.js.org/yennj12_blog_V4/tags/pubsub/Recent content in PubSub on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-11-async-event-driven-pipeline-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-11-async-event-driven-pipeline-zh/核心定義：Async Event-Driven Pipeline 是將每個長時間運算（如 LLM 推論）拆成「接受請求 → 寫訊息佇列 → 立即回 202 → 背景 Worker 處理 → 客戶端輪詢或推送結果」五個步驟，徹底切斷 HTTP 連線與運算時間的綁定關係，讓連線池資源不再成為系統瓶頸。 面試情境： 「你們的 AI 寫作助理功能在發布後一週內，DAU 從 500 成長到 8,000，但後端開始出現大量 503，LLM 回應也從 3 秒變成 30 秒超時。你作為 FDE，如何診斷問題並提出架構改善方案？你的方案需要能支撐 50,000 DAU 而不需要垂直升級 LLM endpoint。」 一、為什麼面試官問這個 面試官真正在測試的是你對連線資源生命週期與系統容量天花板的直覺，以及你能否在架構層面解決「延遲長」這個根本矛盾，而不是靠「加機器」硬撐。這題在 FDE 面試中特別常見，因為 LLM 整合幾乎是現代應用的標配，而 LLM 的推論延遲（2–30 秒）與 Web Server 的同步模型之間存在根本性衝突。 測試點一：容量計算能力。 你能否當場估算「1,000 並發 × 15 秒 LLM 延遲 = 需要同時持有 1,000 個連線」，並說明為什麼典型的 Gunicorn + FastAPI 配置在 200–500 個並發時就會開始出現 503。面試官想看到的是工程師對資源約束的量化思維，而不是模糊的「系統會變慢」。