各サービスが独自のデータベースを持つ場合、データをどのように管理しますか?

Question

Accepted Answer

**共有データベースがない**場合、サービス間の JOIN やシングル ACID トランザクションは使用できません。データを構成し、**API コンポジション**、**レプリケーション/CQRS 読み取りモデル**、および**イベント**を使用して一貫性を保ちます。

## サービス間でのデータ読み取り

**API コンポジション** — コーディネーターが各サービスを呼び出し、結果を組み立てます:

```js
// build an order view from three services
const order    = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId);   // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
```

重いクエリの場合は、**読み取りモデル**(CQRS)を維持します: サービスはイベントにサブスクライブし、直接クエリできる非正規化されたローカルコピーを構築します。

```text
Orders ─event→ ┐
Users  ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
```

## サービス間での書き込み

分散トランザクションの代わりに**Saga**パターンを使用します — 補償アクションを伴う一連のローカルトランザクション。

## トレードオフ

| アプローチ | 利点 | 欠点 |
|---|---|---|
| API コンポジション | 常に最新 | レイテンシ、ファンアウト、脆弱 |
| レプリケートされた読み取りモデル | 高速な読み取り | 最終的一貫性 |
| Saga | 2PC 不要 | 複雑、補償が必要 |

## 落とし穴

JOIN を簡単にするために単に「テーブルを共有する」ことはしないでください — これはサービスを再び結合します。ビジネスが許可する場合は、最終的一貫性を受け入れます。

## なぜ重要なのか

データ管理はマイクロサービスが本当に難しくなるところです。なぜなら、簡単なツール(JOIN、トランザクション)は設計上削除されているからです。

コンポジション、読み取りモデル、サガを理解することが、正確性を失わずにサービスを独立させておくことができるのです。

アプローチ	利点	欠点
API コンポジション	常に最新	レイテンシ、ファンアウト、脆弱
レプリケートされた読み取りモデル	高速な読み取り	最終的一貫性
Saga	2PC 不要	複雑、補償が必要