🧨Day 23 — 刪掉 1982 行程式碼後，我靈魂都變輕了！

今天是那種「砍掉重練、世界清淨」的一天。
沒錯，我正式和 BatchService 分手了。
這段關係維持太久，該放手的時候就該瀟灑地按下 git rm。

🪓 BatchService，被我一刀斬了

BatchService 本來是個「看起來很強、其實很複雜」的功能。
有自己的 handler、有 repository、有 service、有一堆表，
就像某些設計太精美的咖啡機一樣——按鈕多、燈會閃，但你只想泡一杯熱水。

於是我決定：

「再見了，我要回歸簡潔的通知人生 ☀️」

• 刪掉了 11 個文件
• 移除了 3 個整個檔案
• 減少 1,982 行 代碼（這不是重構，是一場放生）

OpenAPI、schema、trigger、甚至 batch_summary 全都清理。
程式碼少了，腦袋也清醒了。Compile 一次沒報錯時，
我感覺自己升天了。

⚙️ 架構新生：Redis 才是靈魂主角

既然 BatchService 不在了，系統乾脆直接進化成 Redis 驅動架構！
DB 查詢？掰掰。
ActorPool 自己拉資料？掰掰。
一切交給 Redis：

API Request → DB + Redis Queue → QueueConsumer → ActorPool

QueueConsumer 才是真正的節奏大師 🎶
從 Redis 拉資料、交給 ActorPool Spawn。
Redis 跑得快、腦袋輕、延遲低。
整個架構乾淨俐落，連 Debug 都順眼。

🧠 新技能上線：不再掉任務！

之前的 QueueConsumer 有點「健忘」，
pool 滿時它會把任務吞掉，就像吃進嘴裡卻沒咬就吞下。

現在我加了：

• 容量檢查：先看有沒有空間再 dequeue
• RequeueToFront：失敗任務立刻重排回前端
• SETNX 保護機制：多節點下保證唯一消費
• 429 延遲支援：Teams API 卡時不堵整條隊列

高優先級的任務不會被「擠到後面」，
QueueConsumer 變成有禮貌又高效率的任務調度員。

🧩 NotificationProcessor：我組了一支夢之隊

還記得以前初始化 ActorPool、QueueConsumer 時那種繁瑣感嗎？
現在我給它們包成一個新模組：

type NotificationProcessor struct {
    pool     *ActorPool
    consumer *QueueConsumer
}

一鍵啟動，整個系統都會跟著甦醒。
程式碼少了三分之一，看起來順眼多了。
這感覺就像打掃房間後看到地板——我居然忘了原來是木紋的。

🔄 狀態管理與重試機制：通知也要有生命週期

以前通知進 queue 成功或失敗，都只能靠 log 祈禱。
現在它有了清楚的生命週期：

pending → enqueued → sent
   ↓         ↓
failed ← failed

加上 NotificationScanner 自動掃描 pending 狀態、重試 enqueue，
而且還有最大重試次數。
這樣一來，不怕一時失敗、也不會無限輪迴。
工程師和通知都值得被善待 ❤️

🩹 最後修補：Batch 迴圈 & 狀態競爭

發現多個 destination 更新同一個 notification 時，狀態會打架。
我立刻修正：

• 每個 notification 只更新一次狀態
• 統計整體 enqueue 結果再決定狀態
• 重試耗盡才標記為 failed

結果：再也沒有「誰先更新誰贏」的修羅場。

🧾 結語：程式碼減肥，也是一種修行

今天刪了近兩千行，整個 repo 看起來像剛洗完澡一樣乾淨。
Redis 架構跑起來又穩又快，通知狀態乾淨透明，
而我呢？
只想高喊一句：

「Simple is powerful，Refactor is Zen.」

接下來的日子，我會繼續優化 ActorPool、觀測 Redis 隊列、
然後寫更多讓人笑著學技術的日誌。
畢竟，工程師的浪漫，就是在一堆 log 裡找到秩序 🧘‍♂️