Микросервисы часто вводят ради автономности команд. Но если все сервисы продолжают работать с одной общей базой и напрямую читать таблицы друг друга, независимость быстро заканчивается.
Команда хочет изменить структуру данных — и сначала должна проверить, кто ещё использует эту таблицу. Новый релиз одного сервиса зависит от запросов другого. Ошибка в схеме данных становится общей проблемой.
Database per Service предлагает более жёсткую границу: каждый сервис владеет своими данными, а остальные получают их через контракт, а не через прямой доступ к таблицам.
Какую проблему мы решаем
Общая база создаёт скрытую связанность. Сервисы могут выглядеть независимыми на диаграмме, но оставаться связанными через схему данных.
Если сервис заказов владеет своими таблицами, а сервис платежей — своими, изменения внутри одного домена меньше затрагивают другой. Внешнее взаимодействие идёт через API, события или другие договорённые интерфейсы.
Это делает границу владения не только организационной, но и технической.
Что получает бизнес
Главная выгода для бизнеса — меньше координации вокруг изменений.
Когда команды действительно владеют своими данными, им проще выпускать изменения независимо и не превращать каждую миграцию базы в общий проект для нескольких подразделений.
Это особенно важно в большой продуктовой организации, где скорость начинает теряться не на написании кода, а на количестве зависимостей между командами.
Есть и риск-эффект: ошибка одной команды меньше шансов повредить данные другого домена напрямую.
Но бизнес получает эту автономность не бесплатно. Чем сильнее данные разделены, тем больше работы появляется там, где нужно собрать целостную картину по нескольким доменам.
Что получает команда
Команда получает право менять собственную модель данных без постоянного страха сломать чужой SQL-запрос.
Она может выбирать структуру хранения под свой сценарий, планировать миграции в своём ритме и лучше контролировать производительность своего сервиса.
Граница ответственности становится яснее: если данные принадлежат сервису, он отвечает за их качество и предоставляет другим согласованный способ доступа.
Что получает клиент
Клиент редко видит, как разделены базы. Он замечает косвенный эффект: команды могут быстрее менять отдельные части продукта и реже блокировать друг друга.
Но клиент может столкнуться и с ценой подхода: некоторые данные обновляются не мгновенно, а с задержкой, если между сервисами используется асинхронный обмен.
Поэтому архитектурная автономность должна учитывать реальные ожидания клиента по актуальности информации.
Чем мы за это платим
Самая большая цена — потеря простоты общей транзакции и обычного SQL через все данные сразу.
Если заказ, платёж и доставка хранятся отдельно, нельзя просто сделать один JOIN и получить всю картину. Нужны API, события, отдельные read-модели, витрины или другие способы объединения.
Появляется eventual consistency: разные части системы могут какое-то время видеть разные состояния одного бизнес-процесса.
Усложняются аналитика, резервное копирование, восстановление, миграции и расследование инцидентов, затрагивающих несколько сервисов.
Когда отдельная база на сервис не нужна
Если сервисы фактически развивает одна небольшая команда, изменения выпускаются вместе, а бизнесу не нужна независимость частей системы, строгая изоляция данных может быть лишней.
Иногда общая база с хорошо определённым владением схемами даёт достаточно порядка без полной распределённости.
Что стоит спросить перед решением
- Нас действительно тормозят согласования изменений общей схемы?
- Должны ли команды выпускать изменения независимо?
- Какие бизнес-процессы требуют данных сразу из нескольких доменов?
- Допустима ли задержка между изменением данных в разных сервисах?
- Готовы ли мы строить отдельные механизмы для аналитики и сквозных запросов?
В итоге
Database per Service — это не правило «у каждого микросервиса должна быть своя PostgreSQL». Смысл в другом: сервис должен владеть своими данными, а другие не должны зависеть от его внутренних таблиц.
Бизнес покупает автономность команд, но платит за неё более сложной работой с данными между границами. Если независимость не нужна, цена может оказаться выше выгоды.