Database per Service

Сервис должен владеть своими данными

Подход Database per Service означает, что данные одного сервиса не являются общей внутренней базой для остальных. Другие компоненты получают нужную информацию через контракт владельца, а не выполняют запросы к его таблицам напрямую.

Orders Service  -> Orders DB
Payments Service -> Payments DB

Payments Service -X-> Orders DB

Физически это не всегда требует отдельного сервера базы данных. Важна логическая собственность: только сервис-владелец управляет своей моделью данных и может безопасно менять её без скрытых потребителей.

Общая база создаёт скрытую связанность

Когда несколько сервисов читают и изменяют одни таблицы, схема становится общим API без явной версии. Переименование столбца или изменение структуры уже нельзя сделать локально, а бизнес-правила легко обходятся прямой записью из соседнего сервиса.

Собственное хранилище заставляет взаимодействовать через явные контракты и лучше сохраняет границу ответственности. Но данные теперь распределены, поэтому привычный JOIN между всеми сущностями и одна общая транзакция становятся недоступны как универсальное решение.

Дублирование данных иногда допустимо

Сервис может хранить локальное представление информации, полученной от другого владельца, если это нужно для автономной работы или быстрых чтений. Такое представление должно иметь понятный источник истины и способ обновления, иначе копии начнут незаметно расходиться.