マイクロサービス──独立 DB か共有 DB か（6 人チーム・50 万ユーザー）

問い

チーム 6 人・50 万ユーザー・急成長中。

エンジニア A「すべてのサービスはそれぞれ独自の DB を持つべき。それが本物のマイクロサービス。」

エンジニア B「サービスに明確な境界があれば共有 DB でも問題ない。個別 DB は運用上の複雑さを増すだけでまだ必要ない。」

どちらが正しいか？この決定を下すべき唯一の要因は何か？

2 つの立場の整理

観点	独立 DB（エンジニア A）	共有 DB（エンジニア B）
理念	本物のマイクロサービス、完全な疎結合	境界が明確なら共有でも疎結合を達成できる
運用コスト	DB 数×運用・監視・バックアップが必要	1 DB の運用で済む（6 人チームには現実的）
デプロイ独立性	サービスごとに独立したリリースが容易	スキーマ変更の影響が他サービスに波及しうる
スケール	サービスごとに独立したスケーリング可能	ボトルネックが共有化される

「唯一の要因」の考え方

• デプロイ独立性の要件があるかが最も重要な判断軸

• サービス A のデプロイがサービス B に影響なく行えるか？ → 影響が出るなら独立 DB が必要

• 6 人チームで複数 DB の運用はオーバーヘッドが大きい → 境界が明確で今は共有でも可

• 将来分離するコストも考慮する（シームレストランザクションが共有 DB を強制していないか）

実践的な指針

• スキーマを論理的に分離（テーブルの所有権をサービスごとに明確化）すれば、物理 DB が共有でも疎結合に近い状態を維持できる

• 他サービスのテーブルに直接 JOIN しない規律を守る

• 急成長中であれば、スケールが求められる時点で独立 DB へ移行するロードマップを持つ