イベント駆動は『疎結合と非同期処理』の鍵
イベント駆動アーキテクチャ（EDA）は、サービス間を直接呼び出さず、イベントを介して疎結合に連携する設計手法です。Pub/Sub・メッセージキュー・イベントストアなど複数の道具があり、用途で使い分けます。本記事では、EDA の実装パターンを編集部の視点で整理します。マイクロサービス設計ロードマップ もご参考に。
イベント駆動の特徴
(1) 疎結合：送信側が受信側を知らない。(2) 非同期：応答を待たない。(3) 拡張性：受信側の追加が容易。(4) 耐障害性：一部障害が伝播しにくい。(5) 追跡性：イベントログが履歴になる。REST API設計 との対比で理解しやすいです。
主要なメッセージング基盤
(1) Apache Kafka：大規模ストリーミング。(2) RabbitMQ：従来型キュー。(3) AWS SNS/SQS：マネージド Pub/Sub・キュー。(4) Google Cloud Pub/Sub：マネージド Pub/Sub。(5) Redis Streams：軽量ストリーミング。規模・運用負荷・既存基盤で選びます。Cloudflare活用ガイド もご参考に（Queues）。
キューと Pub/Sub の違い
(1) キュー：1メッセージ→1コンシューマ。(2) Pub/Sub：1メッセージ→複数サブスクライバ。(3) 使い分け：タスク処理→キュー、通知配信→Pub/Sub。(4) ハイブリッド：SNS→SQS の組み合わせ等。(5) 順序保証：必要かどうかで設計変化。SREへの転身ガイド もご参考に。
イベント設計のコツ
(1) 過去形で命名：OrderCreated・UserSignedUp。(2) 自己完結：他テーブル参照なしで意味が分かる。(3) スキーマ管理：Avro・Protobuf 等。(4) バージョニング：後方互換。(5) イベント粒度：細かすぎず粗すぎず。「呼び出し」ではなく「事実の通知」を表現します。
典型的なパターン
(1) Event Notification：通知のみ。(2) Event-Carried State Transfer：状態を含めて配信。(3) Event Sourcing：状態をイベント列で表現。(4) CQRS：読み書きの分離。(5) Saga：分散トランザクション。データベース基礎 もご参考に。
冪等性と信頼性
(1) At-least-once 配信が標準：重複に備える。(2) 冪等性の実装：重複処理が安全。(3) イベント ID の活用：重複検知。(4) デッドレターキュー：失敗イベントの隔離。(5) 再処理機構：失敗からの復帰。「重複は来る前提」で設計するのが鉄則です。
監視とデバッグ
(1) 分散トレース：イベントを跨いだ追跡。(2) メッセージの可視化：管理画面。(3) 遅延監視：キューの滞留。(4) 消費者ラグ：処理遅れの検知。(5) 監査ログ：イベント全履歴。オブザーバビリティ実践 もご参考に。
失敗しがちなパターン
(1) 同期 RPC として使う：EDA の利点を失う。(2) 冪等性なし：重複処理で事故。(3) イベントが多すぎ：何が起きているか不明。(4) スキーマ管理なし：互換性破壊。(5) DLQ 放置：失敗が積み上がる。対策は、(1)非同期前提、(2)冪等性、(3)粒度設計、(4)スキーマ管理、(5)DLQ 監視、です。IT・Web業界の職種完全マップ もご活用ください。