Когда лучше использовать монолит вместо микросервисов
Что проверяют
Считаете ли вы стоимость архитектуры или повторяете моду. Сильный ответ показывает понимание: микросервисы это способ развести команды и релизные циклы, а не приём ускорения кода. Следом обычно спрашивают, как выделять сервис из монолита, когда он всё-таки понадобится.
Как отвечать
Назовите условия, при которых монолит правильный выбор:
- небольшая команда: пока разработчиков меньше двух-трёх команд, независимые релизы никому не нужны, а накладные расходы уже есть;
- домен не устоялся: границы контекстов будут переезжать. Внутри монолита это рефакторинг на день, между сервисами это миграция контрактов, данных и двух пайплайнов;
- сильная транзакционность: одна транзакция базы вместо саг, компенсаций и разговоров про согласованность в конечном счёте;
- умеренная нагрузка: монолит отлично масштабируется горизонтально, несколько экземпляров за балансировщиком. Узким местом обычно оказывается база, и микросервисы её не чинят;
- нет команды эксплуатации: распределённая трассировка, обнаружение сервисов, отдельные конвейеры и дежурства требуют людей, которых у небольшого продукта нет.
Дальше главное: правильный ответ звучит не «монолит», а «модульный монолит». В .NET это отдельные проекты по ограниченным контекстам, публичный контракт модуля в виде интерфейсов, обращение только через него, обмен сообщениями в пределах процесса, у каждого модуля своя схема в базе и запрет читать чужие таблицы напрямую. Границы фиксируются архитектурным тестом (NetArchTest, ArchUnitNET), иначе они размоются за квартал. Когда модуль получает свою нагрузку и свою команду, он выносится в сервис почти механически.
Отдельно упомяните антипаттерн: распределённый монолит, где сервисы деплоятся только вместе и связаны цепочками синхронных вызовов. Это худшее из двух миров.
Где спотыкаются
Заявляют, что монолит нельзя масштабировать. Можно, и обычно дешевле.
Обсуждают только технику и молчат про команды, релизы и дежурства, хотя решение принимается именно там.
Предлагают «сразу микросервисы, чтобы потом не переписывать». На неустоявшемся домене это гарантированный болезненный перенос границ, только уже через сеть.