プロダクトバックエンドのためのイベント駆動設計

ビジネスについての事実を発行する

有用なイベントは、起きた意味のあることを記述する：注文が置かれた、録音が処理された、メンバーシップがアップグレードされた。データベース行のダンプでも、偽装されたリモート手続き呼び出しでもない。過去形で命名し、おしゃべりなコールバックなしにコンシューマが行動できる十分な文脈を含めろ。

ペイロードをバージョン管理しろ。コンシューマは異なるスケジュールで進化し、破壊的なフィールド改名はチーム横断の静かな失敗に連鎖しうる。

意図してコンシューマを隔離する

各コンシューマは特定の成果を所有すべきだ：メール送信、検索インデックス更新、権利付与、分析通知。無関係な副作用に一つの巨大ワーカーを共有すると、より悪い失敗モードを持つモノリスを再現する。

バックプレッシャー、リトライ、デッドレターキューはコンシューマごとだ。通知の毒メッセージが検索インデックスを止めてはならない。

• ハンドラをデフォルトで冪等にする
• 重複排除キー付きの少なくとも1回配信を好む
• 順序保証を正直に文書化する
• 発行と消費をまたいで本番フローをトレースする

一貫性のトレードオフを受け入れる

イベント駆動システムはしばしば結果整合性を受け入れる。プロダクトコピーとUIは、一部の状態が非同期で追いつくことを認めねばならない。すべての副作用が瞬時だと偽るより、処理中状態を示す方がよい。

強い一貫性が要るところ——残高、在庫予約、一意制約——では、その論理をトランザクション境界に保ち、コミット後にイベントを発行しろ。

コレオグラフィを運用する

相関ID、ラグ指標、リプレイツールがなければ、イベントシステムは神秘になる。バグ修正後にイベントのウィンドウを安全に再処理する能力を構築しろ。コンシューマラグをユーザー向け信頼性シグナルとして測れ。

コア取引パスを不安定化せずにコンシューマ追加でプロダクト振る舞いを拡張できるとき、イベント駆動設計は報われる。