Стартап начинает новый продукт и спрашивает: сразу микросервисы или монолит? Что вы порекомендуете и почему?
- С чего начинать новый проект — монолит или микросервисы?
- Что такое модульный монолит?
Модульный монолит: границы внутри процесса стоят дёшево и переносятся рефакторингом, а границы сервисов закрепляются сетевым контрактом и стоят дорого.
- В начале предметная область ещё не понятна — граница наверняка будет неверной
- Постоянный налог микросервисов маленькой команде не по силам
- Модули с явным API, своими таблицами и запретом JOIN через границу — потом режутся по готовым швам
А ещё Выделять сервис, когда появляется организационная или нагрузочная причина
Подробно
Рекомендация — начать с модульного монолита и сказать это прямо.
Почему. В начале проекта предметная область понятна плохо, и первые границы почти всегда окажутся неверными. Граница внутри монолита переносится рефакторингом за день; граница сервиса закреплена API, развёртыванием и миграцией данных — переделка занимает месяцы. Кроме того, микросервисы требуют постоянных вложений: CI/CD на каждый сервис, наблюдаемость и трассировка, контракты и их версионирование, локальное окружение, дежурства. Маленькая команда тратит на это силы, которые нужны продукту.
Как сделать монолит готовым к разделению:
- модули по бизнес-возможностям с явным публичным API;
- у модуля свои таблицы, запрет прямых JOIN и записей в чужие таблицы;
- взаимодействие модулей через интерфейсы и внутренние события;
- проверка правил зависимостей в сборке (ArchUnit, import-linter).
Когда выделять сервис: растут команды и мешают друг другу выкатками; у части системы резко другие требования к масштабированию, надёжности или стеку; нужна изоляция по безопасности. Тогда модуль режется по уже существующему шву. И обратное движение — объединение сервисов — тоже нормальное решение.
Что хотят услышать
- Прямая рекомендация и обоснование через стоимость ошибки в границах.
- Налог микросервисов для маленькой команды.
- Практики модульного монолита.
- Критерии, когда выделять сервисы.
Частые ошибки
- Отвечать «зависит» без рекомендации.
- Предлагать микросервисы «на вырост».
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Микросервисы сразу — потом разделить монолит будет почти невозможно
- ✓Модульный монолит, сервисы — по мере причин
- ✗Монолит без внутренних границ: разделение модулей замедлит команду, а режут потом по таблицам базы данных
- ✗Serverless-функции на каждый эндпоинт, чтобы не думать о границах
Что спросят дальше
- Как вы будете следить, что модули не срастаются?
- Какой первый сервис вы бы выделили и почему?
Разбор темы
- Монолит, микросервисы и границы сервисов
Когда микросервисы оправданы, а когда вредны; bounded context и DDD как способ резать систему; распределённый монолит и его признаки; база на сервис и организационная цена.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.