Transaction log tailingパターン
メッセージ発行の信頼性を担保するためのパターン
Outboxパターンの文脈でしか出てこないのかは知らんので、具体化して書いてる↓mrsekut.icon 仕組み
ビジネスデータの更新と「送りたいメッセージ」を、同じDBトランザクション内で書き込む
ここがこのパターンの本体mrsekut.icon
アプリのテーブルへのINSERT/UPDATE/DELETEはすべてこのログに記録される
ので、それを「あたかもレプリカDBであるかのように」末尾を追いかけて読み取り、outboxへの追記を検知してイベントに変換し、ブローカーへpublishする
pros
コミットされた瞬間にログに乗るので、ほぼリアルタイム
DBへの追加負荷が小さい
アプリコードに手を入れにくい
場合によってはoutboxテーブルすら不要で、業務テーブルへの変更を直接CDCで拾う設計も可能
cons
インフラが複雑
DB依存
WAL/binlogのフォーマットや論理レプリケーション設定に依存する
DB固有の知識が要る
ツール