Outboxパターン

基本アイデア

発行は後で別プロセスがやる

code:mermaid

flowchart TD

end

業務データとイベントが同じトランザクションに入るので、片方だけ成功は原理的に起きない

outboxに溜まったレコードをブローカーへ送る方法は主に2つ

別プロセスが定期的にoutboxテーブルを見て、メッセージブローカーにpublishする

小規模〜中規模ならこれで十分

DB自身のトランザクションログを末尾から読み取って、変更を検知してブローカーに流す

table:_

Polling Publisher Log Tailing (CDC)

実装 シンプル やや複雑（CDC基盤が必要）

負荷 ポーリング負荷あり 低い

レイテンシ 間隔依存 低い

依存 DBだけ DB log読取の仕組み

冪等性を担保した設計にすること

outbox tableからメッセージブローカーに送る部分

outbox パターンが保証するのは、at-least-once（最低1回） であって、exactly-once ではない

複数回メッセージブローカーに同じリクエストを送ることがありうるので、冪等でないといけない

er.g. 発行はしたが published フラグの更新前にクラッシュしたので、再起動後に同じイベントを再送