【アウトボックスパターン】

Outboxパターンとは？

最終更新: 2026年10月2日

💡 業務データと送信予定を、一緒に保存

業務データと送信予定のイベントを同じDBトランザクションで保存し、別の処理が配信する設計。二重書き込みの問題、再試行、重複処理や順序への対策を解説します。

📌 このページのポイント

確定した送信予定をあとから配信します。受信までDBトランザクションに含める意味ではなく、一度だけの配送・処理は別に対策が必要です。

ひよこ

注文の保存と通知が、食い違うことがある？

ペンギン先生

DBへの注文の保存と、別システムへのイベント送信を別々に行うと、片方だけ成功することがあるよ。注文は保存できたのに通知できない、保存できなかったのに通知だけ出る、といった不整合が問題なんだ。

ひよこ

Outboxでは、どうする？

ペンギン先生

注文データと送信予定のイベントを、同じDBトランザクションで保存するよ。両方を確定するか、両方を取り消す。そのあと別の配信処理が、確定した送信予定をメッセージブローカーなどへ送るんだ。

ひよこ

保存できた瞬間に、相手へ届く？

ペンギン先生

保存と相手への配送は別の段階だよ。送信予定を定期的に読むポーリングや、変更ログを捉えるCDCで配信する。DBに保存しただけでは届かないので、配信処理が動いているか、未配信が増えていないか確認する。

ひよこ

配信に失敗したら？

ペンギン先生

記録されたイベントを元に再試行できるようにするよ。ただ、送信は成功したのに配信済みの記録に失敗すると、もう一度送る可能性がある。受信側もイベントIDなどで重複を識別し、同じ注文を二重に処理しない設計が必要なんだ。

ひよこ

専用の製品が必要？

ペンギン先生

設計パターンだから、特定製品は必須ではないよ。DebeziumにはOutboxテーブルの変更を捉え、イベントへ変換する仕組みがある。ポーリングで作ることもできる。DB、配信先、再試行や順序の要件に合わせて選ぶんだ。

もっと詳しく知りたい人へ

Outboxなら、必ず一度だけ届く？

このパターンだけでは、一度だけの配送や処理は保証しません。再試行で重複する場合に備え、受信側の冪等性や重複判定、配信済みの管理を設計します。失敗が続くイベントの監視と対応も必要です。

保存順と配信・処理の順序をどう保つかは、別に設計します。並列処理、再試行、配信先の仕様も関係します。たとえばDebeziumの説明では、集約IDをKafkaのメッセージキーに用い、パーティション内の順序に関係付けています。

まとめ：ざっくりこれだけ覚えればOK！

「Outboxパターン」って出てきたら「業務データと送信予定を一緒に保存し、あとでイベントを配信する仕組み」と思えばだいたいOK！

📖 おまけ：英語の意味

「Transactional Outbox Pattern」＝トランザクションで送信予定を保存する設計

💬 Outboxは送信トレイです。業務データの更新と、送りたいイベントの記録を一つのトランザクションにまとめます。