要点: ブローカーが順序を保証する範囲は限定的です。業務側が、何を同じ順序で扱うか決める必要があります。
この記事の用語: 順序制御：イベント順序。重複排除：重複排除。再実行：履歴イベントを再実行すること。
現場の課題
全体順序は並列性を失わせます。再試行は重複を生み、遅れて届いたイベントは新しい状態を上書きします。履歴再実行でメールや決済を再送する危険もあります。
順序保証はパーティションなど限定範囲です。業務オブジェクトごとに必要な順序を決め、コンシューマーはバージョン、重複排除、外部作用の分離で遅延イベントと再実行へ備えます。
設計と実装
- 順序を守る業務範囲と一致するパーティションキーを選びます。
- イベントID、オブジェクトID、オブジェクトバージョン、発生時刻をすべてのイベントへ含めます。
- 履歴再構築と、メール・決済などの外部作用を分離します。
実装例
if inbox.contains(event.id): ACK
current = projection.version(event.aggregateId)
if event.version <= current: ACK
if event.version > current + 1: park(event)
transaction(apply(event), inbox.add(event.id))
ACK本番導入の進め方
イベントID、オブジェクトバージョン、観測メトリクスを先に追加します。一コンシューマーへ受信済みテーブル 重複排除を導入し、再実行専用環境で全履歴を訓練してから障害対応で使います。
まとめ
イベント処理の正しさは、明確な順序保証の範囲と決定的なコンシューマーから生まれます。