前置き
前回の記事の続きで、今回もイベントメッシュについて触れていきます。
今回は
どんな時にイベントメッシュが必要になってくると判断するのか？
を追っていきましょう。
イベントの数が少ないうちは不要
大量のイベント駆動が適用されていない状況では、イベントメッシュは不要です。
イベントメッシュは、「イベント・スパゲッティ」（＝どのイベントがどこで使われているか分からないカオス状態）という、大規模な分散システムが抱える「複雑さ」 を解決するためのインフラです。
なぜ不要か？ (YAGNIの原則)
もし、サービスが数個しかなく、イベントの種類も少ない（＝大量のイベント駆動が適用されていない）ならば、単一のメッセージブローカー（KafkaやRabbitMQなど） で十分管理できます。
この段階でイベントメッシュ（高度なルーティング、カタログ、ガバナンス機能を持つ基盤）を導入するのは、YAGNI原則に反する 過剰設計 です。
どの程度の「量」や「複雑さ」になったら検討すべきか
導入を検討すべきトリガーは、イベントの「量」だけではありません。
むしろ、「組織的な複雑さ」 の方が重要なシグナルです。
イベントメッシュを導入すべき定量的な判断根拠としては、以下の 痛み を計測すべきです。
1. 組織と技術の「分断」
定量的根拠
(A) 複数の部門/チームが、ドメインをまたいでイベントを共有し始めた数。（例: 5チーム以上）
(B) 2種類以上のメッセージング技術（例: KafkaとSQS）や異なるクラウド（例: オンプレミスとGCP）間でのイベント連携が必要になった数。
判断
これらの「分断」が発生すると、単一のブローカーでは管理できません。
技術や組織の 「サイロ」 を越えてイベントをルーティングするために、イベントメッシュが必要になります。
2. ガバナンスの「失敗率」
定量的根拠
(C) スキーマ（イベント形式）の破壊的変更によって、下流のコンシューマー（消費者）が障害を起こした回数。（例: 四半期に2回以上）
判断
「野良イベント」が横行し、ガバナンスが効かなくなっている証拠です。
スキーマレジストリやバージョン管理を強制できるイベントメッシュが必要になります。
3. 開発の「リードタイム」
定量的根拠
(D) 開発者が「必要なイベントを見つける」のにかかった時間。（例: 開発者アンケートでの「イベント発見の困難さ」のスコア）
(E) 酷似したイベントが「重複」して作られた数。（例: OrderCreatedイベントが3種類存在する）
判断
イベントの「発見可能性（Discoverability）」が失われています。
開発の生産性が著しく低下しているため、カタログ機能を持つイベントメッシュが必要になります。
結論
念のため、表にもまとめておきます。
イベントの「量」そのものよりも、組織の「複雑さ」や「ガバナンスの失敗」が、
自分たち組織の Four Keys（特にリードタイムや変更障害率）を悪化させ始めたときが、
イベントメッシュの導入を検討すべき定量的なシグナルです。