イベント駆動アーキテクチャの学習を進めているのですが、実際に触れてないので自前で簡単なもの作って理解を深めようという試み。この記事はやること書いて実装は明日以降する予定。

はじめに

イベント駆動アーキテクチャ（Event-Driven Architecture）は、マイクロサービス間の疎結合な連携を実現する強力なアーキテクチャパターンです。KafkaやRabbitMQ、AWS Kinesisなど様々なメッセージングプロダクトがありますが、これらを使わずに本質的な概念だけでシンプルに実装してイベント駆動アーキテクチャの核心的な仕組みを理解することを目指します。

イベント駆動アーキテクチャとは？

従来のリクエスト-レスポンス型の通信では、サービス間が直接依存し合います。一方、イベント駆動アーキテクチャでは：

プロデューサー（生産者） がイベントを発行
トピックにイベントが保存される
コンシューマー（消費者） が必要なイベントを読み取って処理

この仕組みにより、サービス間の疎結合が実現され、新しいサービスの追加や障害からの復旧が容易になります。

イベント駆動アーキテクチャの利点

実装を通じて、以下の利点が実感できます（のはず）

疎結合

プロデューサーはコンシューマーを知らない
新しいサービスを追加しても既存サービスに影響なし

拡張性

新しいコンシューマーを後から追加できる
過去のイベントを再生して初期データを構築

障害耐性

イベントは削除されないため、データの復旧が可能
オフセット管理により、クラッシュ後も続きから処理

監査可能性

全てのイベント履歴が残る
何が起きたかを時系列で追跡可能

イベントソーシング

イベントが「真実の源泉（Source of Truth）」
任意の時点の状態を再構築可能

実装する予定の機能

今回実装する主要な機能：

トピック - イベントを永続化（消費されても削除されない）
プロデューサー - イベントを発行
コンシューマー - イベントを取得・処理
オフセット管理 - 各コンシューマーの読み取り位置を記録
冪等性 - 同じイベントを複数回処理しても結果が変わらない
障害復旧 - クラッシュ後も中断した位置から再開

確認用シナリオ

シナリオ1: 基本的なフロー
注文が作成され、在庫サービスが在庫を減らします。

シナリオ2: 新しいコンシューマーの追加
システム稼働中に売上集計サービスを追加します。過去のイベントを全て再生して集計できます。

シナリオ3: クラッシュと復旧
コンシューマーがクラッシュしても、保存されたオフセットから処理を再開できます。

シナリオ4: 冪等性の確認
同じイベントを複数回処理しても、結果は変わりません。

続く