Почему действует правило «одна база данных на сервис»?
- Почему у каждого микросервиса своя база?
- Как получить данные другого сервиса без общей базы?
Своя база нужна ради независимого изменения схемы и защиты инвариантов: только владелец пишет в свои данные по своим правилам. Дело не в нагрузке.
- Общая база — главный признак распределённого монолита
- Данные чужого сервиса: запрос к владельцу, локальная копия по событиям, отдельная модель чтения
- Цена — согласованность в конечном счёте и отказ от JOIN и общих транзакций
А ещё «Своя база» может быть своей схемой на общем сервере — важна не железка, а владение
Подробно
Почему общая база вредна. Она удобна: JOIN работает, транзакция одна. Но любой сервис может читать и писать чужие таблицы в обход бизнес-правил владельца, а схему уже нельзя менять, не согласовав со всеми читателями. Независимость выкатки и развития пропадает — получается распределённый монолит.
Как получать чужие данные:
- синхронный запрос к API владельца — просто, но связывает доступность и задержки;
- локальная копия через события (event-carried state transfer): владелец публикует изменения, потребитель хранит нужные ему поля. Работает при недоступности владельца, данные отстают;
- отдельная модель чтения (CQRS) — собранная из событий нескольких сервисов для запросов, которые иначе требовали бы JOIN.
Цена: согласованность в конечном счёте, дублирование данных, невозможность общей транзакции — изменения в нескольких сервисах согласуются сагами и outbox.
Важная деталь: «своя база» — это про владение, а не про отдельный сервер. Отдельные схемы и пользователи на одном кластере с запретом доступа к чужим таблицам выполняют правило и экономят эксплуатацию.
Что хотят услышать
- Причины: независимая эволюция схемы и защита инвариантов.
- Способы получать чужие данные и их компромиссы.
- Цена: согласованность в конечном счёте, саги вместо транзакций.
- Своя схема на общем сервере как допустимый вариант.
Частые ошибки
- Объяснять правило нагрузкой на базу.
- Делать синхронный запрос к другому сервису на каждый JOIN.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Потому что разные сервисы обязаны использовать разные СУБД
- ✓Общая база лишает сервисы независимости: схему не поменять отдельно, инварианты не защищены
- ✗Одна база физически не выдерживает нагрузки нескольких сервисов, а JOIN между их таблицами медленный
- ✗Потому что так требует лицензия большинства СУБД
Что спросят дальше
- Как тогда получать данные другого сервиса?
- Что такое event-carried state transfer?
Разбор темы
- Монолит, микросервисы и границы сервисов
Когда микросервисы оправданы, а когда вредны; bounded context и DDD как способ резать систему; распределённый монолит и его признаки; база на сервис и организационная цена.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.