Gymterview
middle

Database per Service или Shared Database -- какой подход выбрать?

Database per Service — это принцип, при котором каждый микросервис владеет собственным хранилищем данных. Shared Database — общая БД для нескольких сервисов. Правильный подход для микросервисов — Database per Service, Shared Database допустим только как временное решение при миграции.

Database per Service

Пример
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ Payment      │  │ Customer     │  │ Notification │
│ Service      │  │ Service      │  │ Service      │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │
┌──────▼───────┐  ┌──────▼───────┐  ┌──────▼───────┐
│ PostgreSQL   │  │ PostgreSQL   │  │  MongoDB     │
│ (payments)   │  │ (customers)  │  │ (notif.)     │
└──────────────┘  └──────────────┘  └──────────────┘
Критерий Database per Service Shared Database
Связность Слабая — сервисы независимы Сильная — общая схема
Хранилище Оптимальное для каждого сервиса Единое для всех
JOIN-запросы Невозможны между базами Простые JOIN
Транзакции Saga (eventual consistency) ACID
Масштабирование БД Независимое Общее
Отказоустойчивость Сбой одной БД не влияет на другие БД — единая точка отказа
Дублирование данных Неизбежно Нет

Компромисс – Schema per Service

Пример
-- Каждый сервис имеет свою схему в одной БД
CREATE SCHEMA payment_service;
CREATE SCHEMA customer_service;

-- Сервисы обращаются ТОЛЬКО к своей схеме
GRANT USAGE ON SCHEMA payment_service TO payment_svc_user;
REVOKE ALL ON SCHEMA customer_service FROM payment_svc_user;

Рекомендации

  • Начинайте с Database per Service — это правильный подход для микросервисов.
  • Если нужны данные другого сервиса — запрашивайте через API, а не через прямой доступ к БД.
  • Shared Database — только как временное решение при миграции с монолита (паттерн Strangler Fig).
  • Для отчётов и аналитики — используйте CQRS с отдельной read-моделью.

На собеседовании: рекомендуйте Database per Service как целевой подход и объясните, почему: слабая связность и независимость. Но покажите, что понимаете цену: Saga вместо ACID и невозможность JOIN. Упомяните Schema per Service как промежуточный шаг.

#microservices