具体的にどういう仕組み？
ECサイトで注文が入ったら「OrderPlaced」イベントを発行。在庫サービスはそれを受けて在庫を減らし、決済サービスは課金処理し、通知サービスはメールを送る。注文サービスは他のサービスの存在を知らなくていい。イベントを発行するだけで、誰がどう処理するかは各サービスの責任なんだよ
リクエスト・レスポンス方式と何が違う？
リクエスト方式は「注文サービスが在庫API→決済API→通知APIを順番に呼ぶ」。1つでも落ちると全体が失敗。イベント駆動は「注文サービスがイベントを発行して完了」。各サービスが独立して処理するから、通知サービスが落ちても注文は成立する。ただし即座に結果がわからないので、結果整合性の設計が必要だよ
デメリットは？
①デバッグが難しい（イベントが飛び交うとフローの追跡が大変）、②結果整合性（最終的には整合するが即座には反映されない）、③イベントの順序保証が必要な場面での複雑さ、④イベントスキーマの管理。分散トレーシング（Jaeger等）やイベントカタログで可観測性を確保することが重要だよ
おもしろい！どういう規模で導入すべき？
モノリスで十分な規模で無理に導入する必要はない。マイクロサービスに分割して、サービス間の依存が複雑になってきたら検討する。最初はAWS EventBridgeやGoogle Cloud Pub/Subのようなマネージドサービスで始めて、需要に応じてKafkaに移行するのが現実的だよ
