Общая база данных выглядит естественно. Все сервисы и модули работают с одними таблицами, данные доступны сразу, транзакции просты, не нужно строить отдельные механизмы синхронизации.
Пока система и команда небольшие, это часто действительно удобно.
Но со временем база может превратиться из общего ресурса в общий центр зависимости.
Какую проблему мы решаем
Shared Database упрощает работу с данными, когда нескольким частям системы нужен единый источник истины и тесное взаимодействие.
Заказ можно создать и тут же обновить остатки. Отчёт может читать те же данные, которые использует основной продукт. Не нужно думать о задержках между копиями данных или передавать каждое изменение через API.
Что получает бизнес
На раннем этапе главная выгода — низкая стоимость разработки и быстрый запуск изменений.
Команде не приходится строить отдельные контракты, очереди и механизмы синхронизации ради каждой операции. Это особенно выгодно, пока одна команда контролирует большую часть продукта.
Но при росте организации экономика меняется. Если пять команд зависят от одной схемы данных, изменение одной таблицы может потребовать анализа всех потребителей, общего окна релиза и длинной цепочки согласований.
Тогда база начинает увеличивать стоимость изменений. Компания платит уже не за хранение данных, а за координацию вокруг них.
Что получает команда
Разработчикам проще выполнять сложные транзакции и получать связанные данные без сетевых вызовов.
Но свобода одной команды ограничивает свободу другой. Если сервис напрямую читает чужие таблицы, владелец этих таблиц уже не может спокойно менять их структуру.
Со временем схема базы фактически превращается в неформальный публичный API, только без версий, контрактов и ясного владельца.
Что получает клиент
На старте клиент может получить более быстрый темп изменений и простую согласованность данных: оплатил заказ — статус и остатки обновились сразу.
Позже та же архитектура может замедлить развитие продукта, если каждая новая функция требует осторожно менять общий слой данных.
Клиент не видит базу. Он видит скорость, ошибки и то, насколько быстро компания может менять продукт.
Чем мы за это платим
Главная цена — связанность.
Команды начинают зависеть от общей схемы, общего окна миграций и общей производительности базы. Ошибочный тяжёлый запрос одного сервиса способен повлиять на остальные.
Также становится труднее отделить часть системы: данные уже переплетены, а границы владения размыты.
Когда общая база перестаёт быть выгодной
- Изменение схемы регулярно требует согласования нескольких команд.
- Сервисы напрямую читают и изменяют таблицы друг друга.
- Отдельным доменам нужны разные требования к нагрузке или доступности.
- Выделение одного сервиса постоянно упирается в общие данные.
- Проблемы производительности одного потребителя влияют на остальных.
Что стоит спросить перед разделением
- Какие данные действительно должны быть общими?
- Кто владеет каждой частью схемы?
- Можем ли мы закрыть прямой доступ и дать другим системам контракт?
- Окупит ли независимость баз дополнительную сложность синхронизации?
В итоге
Shared Database — не ошибка сама по себе. Это дешёвый и сильный инструмент, пока стоимость общей зависимости невелика.
Проблема начинается тогда, когда общая база экономит на инфраструктуре меньше, чем компания теряет на координации и медленных изменениях.