這週回顧起來，都在和llm的微服務奮鬥，為了彈性的機制、金鑰池、供應商、逃生門...等的機制，再到供應商 fallback 機制的完善、Sentry 與 Redis 限流器的整合，每個決策背後都有著更深層的思考和權衡。這些工作或許不太容易被使用者直接感受到，但對產品的穩定性和未來擴展性來說卻至關重要。

重點成就與進展

首先，LLM 微服務終於從 Ingrelens 主專案中成功抽離。雖然過程中遇到不少意外狀況，但目前架構已經相對清晰，API 調用與 fallback 機制也逐步穩定下來。此外，資料庫結構調整成 JSONB 後，雖然短期內有 schema 管理的困擾，但長遠來看，我相信這種彈性會對未來的產品需求更友善。

另外這週的程式碼清理與術語統一也非常值得肯定。雖然刪除過去的程式碼和文件時有點不捨，但每一次清理都是在為未來的自己減輕負擔，讓 Ingrelens 專案更容易維護。

最後錯誤監控與限流機制的整合也完成得相當順利。Sentry 在不同環境的區分讓我對未來問題的追蹤更有信心；Redis 的限流機制則是為了避免未來流量暴增時系統崩潰，這種未雨綢繆的工作，雖然枯燥但必要。

Redis 使用的空間比我想像的還少，幾萬筆資料進去其實才100多mb，但我 Redis那台主機其實開到 8G 記憶體給他用 XD

遇到的挑戰與解決方案

這週最困難的部分，大概就是「彈性 vs 穩定性」的權衡。JSONB 的使用雖然提供了更大的彈性，但也帶來了 schema 驗證和演進的問題。我目前的解法是透過額外的 validation layer 去管理資料格式，未來還會持續觀察是否需要更嚴謹的 schema 管理機制。

供應商 fallback 機制則是另一個意外的大坑。不同供應商的錯誤訊息差異很大，這讓我必須設計更複雜的錯誤處理邏輯來決定何時該切換供應商。雖然目前的解法已經可以應付大部分狀況，但我預期未來還是得定期回頭調整這部分的邏輯，避免 edge cases 的發生。

決策反思與戰略思考

回頭檢視這週的工作，我發現自己有時候還是太容易被眼前的問題拉走注意力，像是原本要專心處理微服務的架構，結果卻花了不少時間在 JSONB 的 schema 管理上。這種情況短期內可能難以避免，但我需要更有意識地區分「短期急迫問題」和「長期架構考量」，避免在戰術層次過度投入，忽略了戰略上的佈局。

從產品層面來看，目前 Ingrelens 的技術架構逐漸往「分散模組化」發展，這是為了未來更靈活的功能擴充與維護性。但這樣的決定也會增加整體的複雜度，未來勢必需要更好的監控與管理工具來維護整個系統的穩定性。

下週規劃與期望（2025-05-19 到 2025-05-25）

下週的重點工作，首先是繼續完善 LLM 微服務，尤其是在效能測試與錯誤監控上。這部分我預計會先跑一輪壓力測試，確認 fallback 機制在高流量狀態下的穩定性。

其次，JSONB schema 管理的問題，我會進一步研究是否有更成熟的工具或框架能夠協助管理 schema validation 與 migration，避免未來資料失控。

另外，產品術語的統一雖然這週已經處理了不少，但我覺得還有其他潛在的問題需要更全面地檢視一次，下週會安排一個半天的時間專門處理這件事。

預期挑戰與應對策略

預期下週最大的挑戰會是 LLM 微服務效能測試後可能曝露的新問題，例如 fallback 機制在高併發下的效能瓶頸或 Redis 限流器的臨界值設定。針對這點，我會提前準備好相關的監控工具，並設定清晰的測試場景，盡早發現並定位問題。

另外，JSONB schema 管理的工具選擇可能會花費不少時間，我必須避免陷入過度工程化的陷阱，適時妥協找到一個能夠快速落地的方案，而非追求完美。

整體而言，這週的進度雖然不完全符合原本的預期，但每個決策的背後都有清晰的戰略思考。創業路上，開坑容易填坑難，重點是能否在每次填坑過程中，為未來的自己留下更好的架構、更清晰的路徑，這才是最值得追求的目標。