👉 アプリを小さな独立した部品（サービス）の集合に分けて作る考え方。
- 1つの大きなシステムを「在庫管理」「決済」「配送」「ユーザ管理」などに分ける
- 各サービスは 独自のデータベースやAPI を持ち、別々に動ける
- チームごとに開発・運用できるので、開発スピードや柔軟性が上がる
マイクロサービスでは「在庫サービス」と「決済サービス」が別サーバ・別DBにあるため、
「すべてを同時に正しく更新（ACID）」するのが難しい。
- 在庫サービス：商品を減らした
- 決済サービス：カード引き落としがまだ届いてない
- 配送サービス：出荷依頼を受け取ってしまった
→ この瞬間は 整合性が崩れる。
目次
だから「最終的整合性」が使われる
マイクロサービスでは「同時に完全一致」よりも、
各サービスが非同期でやり取りし、最終的に揃えばOK という考え方を採用する。
具体例（ネットショップ）
- ユーザーが購入ボタンを押す
- 在庫サービス が商品を減らす（即時反映）
- 決済サービス に非同期でイベントを送る
- 数秒後に 配送サービス が「在庫−決済済み」の情報を確認し、出荷
→ 一瞬ズレがあっても、数秒以内に全体が一致する。
1. マイクロサービスの基本
マイクロサービスは、大きなアプリを「小さなサービスの集合」に分けて作る考え方。
例）ECサイトなら
- 在庫サービス
- 決済サービス
- 配送サービス
- ユーザー管理サービス
といった具合に分けます。
2. データベースの扱い方
ここが重要ポイント。
マイクロサービスでは サービスごとに独自のデータベースを持つ のが基本です。
- 在庫サービス → 在庫DB
- 決済サービス → 決済DB
- 配送サービス → 配送DB
👉 「全サービスが1つの巨大DBを共有」してしまうと、結局モノリシック（一枚岩）に逆戻りするから。
3. メリット
- チームごとに自由にDBを設計できる（RDBでもNoSQLでもOK）
- あるサービスを改修しても、他に影響しにくい
- 障害が部分的にとどまる（決済が落ちても配送は生きてる、など）
4. 課題
- 整合性：サービスをまたぐ処理で「全部同時に更新」が難しい
- 分散トランザクションを避ける設計が主流
- 代わりに「最終的整合性」や「イベント駆動（非同期メッセージ）」で対応する
5. 具体例（ショッピングサイト）
- ユーザーが「購入」ボタンを押す
- 在庫サービスが「在庫 −1」
- そのイベントが決済サービスに飛んで「支払い処理」
- 成功したら配送サービスに「出荷依頼」
ここでは、DBが分かれているので「一瞬ズレる」ことがある。
👉 そこで Eventually Consistent（最終的整合性） が大事になる。
まとめ
- マイクロサービスにおけるDB = サービスごとに独立したデータベース
- これにより柔軟さと独立性は得られるが、ACID一括処理は難しい
- だから「最終的整合性」の考え方がよく使われる
