第十九日：Queue 大改造，優先序三明治 🥪

一、開場：排隊也要講武德

以前我們的 Queue 就像大學福利社排隊：大家一窩蜂衝上去，沒秩序、沒優先權。
今天總算下定決心，把它重構，變成有「優先序」的專業排隊系統。
畢竟通知不是每條訊息都一樣重要，有的急、有的能等，得靠演算法來分流。

二、重構大事紀

今天的 commit 大致可以分成幾個 milestone：

1. 優先序設計

   • 新增 priority 欄位（low | normal | high）。
   • 原本的 urgent 被幹掉，因為誰都覺得自己 urgent。最後統一三層：低、中、高。
   • 簡單明瞭，不怕開會吵半天。

2. Redis 三層佇列實作

   • 採用 Redis List + SETNX 三層佇列設計。
   • high → normal → low，就像三明治的麵包層層堆疊。
   • Producer 丟進去，Consumer 按照優先序消化，不卡死也不亂掉。

3. 舊系統清理

   • 舊版 Queue 全面下架，避免混用。
   • ActorPoolV2 更名回 ActorPool，乾淨俐落。
   • 移除 failed_notifications 的舊引用，避免 Zombie Code 滯留。

4. 文件與 API 更新

   • 重寫架構文件，記錄新的 Queue 設計。
   • API 文件重新整理，跟代碼保持同步。
   • 移除了過時的 validate 端點，減少無謂維護成本。

三、心得：排隊的哲學

今天重構完，回頭想想，其實「Queue 排隊」就跟人生一樣：

• 不可能每件事都 urgent，否則就是沒有優先順序。
• 把需求分級，反而能救急也能穩。
• 舊東西捨不得砍，最後會拖垮系統。

最難的不是寫程式，而是 決定誰該優先。
這其實就是一種 產品哲學：做選擇、立規則、然後堅持下去。

四、明日計畫

• 把新的 Queue 跑壓測，驗證三層設計能不能抗高流量。
• 增加監控指標（高優先佇列長度、處理時間、丟棄率）。
• 模擬極端情境：如果 high 爆滿，normal 和 low 會不會餓死？
• 開始考慮 Dead-Letter Queue，補強容錯能力。

✍️ Day19 收工感言
今天的重構就像幫便利商店安裝「自助收銀」：
再也不是大家急著塞給店員，而是按優先序一個一個處理。
系統看起來乾淨多了，心情也清爽。

只不過，我現在有點擔心：
如果全部人都標 high，這不就回到福利社時代了嗎？ 🤣