マイクロサービスにおけるイベント駆動アーキテクチャとは何ですか?

Question

Accepted Answer

**イベント駆動アーキテクチャ**では、サービスはブローカー（Kafka、RabbitMQなど）を通じて**イベントを生成および消費することで通信**します。サービスは何かが発生したことを宣言し、関心のあるサービスが反応します。プロデューサーはそれらを知る必要もありませんし、待つ必要もありません。

## 仕組み

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## イベントペイロードの例

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## メリット

- **疎結合** — プロデューサーに手を加えることなく新しいコンシューマーを追加できます。
- **レジリエンス** — ブローカーは障害中にイベントをバッファリングします。
- **スケーラビリティ** — コンシューマーは独立してスケールできます。

## 落とし穴

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## なぜ重要なのか

イベント駆動設計により、既存のプロデューサーに変更を加えることなく、単にサブスクライブするだけで機能（分析、不正検知、通知）を追加できます。

その拡張性とレジリエンスは、結果整合性の難しさとデバッグの複雑さを代償にしています。これがイベント駆動に移行するときに受け入れる中心的なトレードオフです。