Jobs queue 兼職 transactional outbox：一張表兩個身分

每個後端遲早要回答同一題：「這個動作要呼叫外部服務，失敗了怎麼辦？」寄信、打 webhook、通知廠商——這些不能跟 HTTP request 同生共死的事，需要「enqueue + 重試 + 死信 + 可觀測」。我把它做成平台的通用積木：一張 background_jobs 表、一個每五秒 tick 的 worker、一組退避重試策略（1m/5m/30m/2h/6h/24h 七次後進死信）。

Handler 的四條鐵律

用了佇列，複雜度不會消失，只是換了形狀。每個 handler 要遵守：

1. 冪等——同一個 job 可能跑一次或兩次，開頭先檢查目標狀態。
2. 自己管 timeout——佇列不會打斷你。
3. 失敗就 throw——默默吞掉例外等於騙佇列說成功了。
4. 不開長交易——worker 會被你卡死。

Newsletter 的確認信寄失敗會自動重試到成功，就是這套機制在扛。

兼職 outbox：真正的巧思

「DB 寫入成功但通知沒發出」與「通知發了但 DB 回滾」是分散式系統的經典兩難。教科書解法是 transactional outbox——把「要做的事」跟業務資料寫進同一個交易。

我的 jobs 表本身就是 outbox：job store 的寫入是 交易感知的，在 txRunner.run() 裡 enqueue，job 列就跟業務寫入原子提交。回滾了，job 從未存在；提交了，worker 在下一個 tick 撿走。常青通知的 fan-out 就是這樣——「寄送紀錄」與「N 個寄信 job」要嘛全部成立，要嘛全部消失。

一個 postgres 才給得起的細節

去重（dedupKey）靠 partial unique index：唯一性只覆蓋 pending/running 狀態的列。job 進入終態，key 自動釋放，下一次同 key 的 enqueue 又能進來。這個設計曾經為了遷就 MySQL（沒有 partial index）繞了一大圈彎路，最後我把支援矩陣收斂到 postgres only，刪掉整層繞道——少支援一個引擎，換來設計的直接了當，這筆帳怎麼算都划算。