第十六日：Redis 工地開張，Worker 開始搬磚

一、開場：從門鎖到物流系統

昨天 API Key 裝上去，算是有了「門鎖」。但門鎖只能保護屋子，還不能確保「通知能送到」。
今天 Codex 升級施工，把系統變成一個小型物流中心：

• Redis 當倉庫（queue）
• Worker 當搬運工
• Teams Token Provider 當報關員（Azure AD 驗證）

Gemini 則扮演工地主任，一邊驗收一邊碎念：「還要加監控！還要做快取！還要記得更新 README！」

二、Codex 的實作紀錄（工地進展）

根據今天的 commit log 與紀錄：

1. TeamsBroadcastService 上線

   • 新增 teams_token_provider.go，用 Client Credentials Flow 向 Azure AD 拿 token，並快取起來避免被 rate limit。
   • TeamsBroadcastService 出發前先去拿 token，然後加上 Authorization: Bearer xxx header 才送消息。

2. Redis Queue + Worker

   • 引入 internal/queue + internal/worker 模組，Worker 從 Redis 拉任務，再呼叫 BroadcastService。
   • Worker 支援 指數回退（exponential backoff），失敗會自動重試，還會紀錄 expvar 指標。
   • 增加 cmd/worker/main.go，現在可以直接跑 go run ./cmd/worker 啟動背景進程。

3. 測試

   • 單元測試：Token Provider、Broadcast Service。
   • 整合測試：用 miniredis + httptest，驗證 queue → worker → webhook 全流程。
   • go test ./... 全部綠 ✅。

4. 文件更新

   • README.md、doc/Requirement.md 都加上了 OAuth、backoff、worker 啟動方法。
   • Commit 訊息也很霸氣：feat(notification): add redis queue worker with teams token auth。

三、Gemini 的專家驗收（工地主任模式）

Gemini 針對今天的成果，提出了幾個建議：

1. Token Caching 要更穩

   • Token 要設 TTL，比實際過期時間略短，避免「剛好過期」出現 401。

2. Retry 要可配置

   • 現在 backoff 是寫死的，建議把 max retry、initial delay 全部做成設定。

3. 監控要升級

   • 已經有 expvar，但最好能暴露 /metrics，讓 Prometheus 可以抓。

4. TeamsBroadcastService 要補完

   • 現在只是能送 http request，未來要能建 Adaptive Card payload，處理不同 Teams endpoint。

5. 文件再補充

   • README 要寫清楚 worker 怎麼跑、怎麼 debug。

一句話總結：「Redis 倉庫建好了，但還需要物流 SOP。」

四、我的復盤

今天的系統正式邁向「可擴展」：

• 從單點 API → 變成 queue + worker 架構。
• 測試已經不是「假裝跑過」，而是用 miniredis 驗證真實流程。

但也有不足：

• retry/backoff 還不夠彈性，之後要抽 config。
• 監控跟 observability 還只是半成品。
• TeamsBroadcastService 還沒真的送到 Teams，只是「Hello World 級別」。

就像今天開了一個物流中心，有倉庫、有叉車，但還沒接到真正的訂單。

五、明日計劃

1. 擴充 TeamsBroadcastService，讓它能真的推訊息到 Teams。
2. 增加 /metrics endpoint，整合 Prometheus。
3. 把 retry/backoff 做成 config-driven，方便調整策略。
4. 增加更多整合測試：失敗重試、多目的地通知。

✍️ Day16 收工感言
今天是重大里程碑：Redis queue + Worker 落地，系統終於能「派工」而不只是「即送即炸」。
雖然廣播還沒真的唱歌，但舞台、燈光、麥克風、搬運工都準備好了。
明天，要讓 Teams 真的聽到我們的聲音。 🚀