Почему решили перейти на микросервисы и что не устраивало в монолите?
Что проверяют
Умеете ли вы обосновывать архитектурное решение проблемами бизнеса и эксплуатации, а не модой. От аналитика ждут двух вещей: названной боли, которую распил лечит, и названной цены, которую за это платят. Ответ показывает, участвовали вы в таком переходе или читали про него.
Как отвечать
Начните с симптомов, а не с названия архитектуры. Причины, которые действительно ведут к разделению:
- разная нагрузка у частей системы: масштабировать нужно один сценарий, а поднимать приходится всё приложение целиком;
- разная скорость изменений: витрину правят еженедельно, расчётное ядро раз в квартал, а релиз общий и потому редкий;
- организационный предел: несколько команд правят один код, выпуск ждёт самую медленную из них;
- разные требования к доступности и данным: отчётность не должна ронять приём заказов.
Дальше про то, что приходит в обмен: сетевой вызов вместо вызова внутри процесса, согласованность в конечном счёте вместо одной транзакции в базе, версионирование контрактов, сквозная трассировка, заметно более дорогое тестирование. Аналитику здесь принадлежит главная часть работы: границы сервисов режутся по бизнес-областям и владению данными, а не по слоям, и на каждый стык нужен описанный контракт и сценарий отказа.
Полезно упомянуть путь: сначала выносят по одному сервису из монолита, оставляя его ядром, и только потом решают, двигаться ли дальше.
Где спотыкаются
Перечисляют преимущества списком из статьи, не связывая их с конкретной болью. Слова про масштабируемость и гибкость без симптома звучат одинаково у того, кто распил вёл, и у того, кто про него читал.
Умалчивают про цену. Собеседник почти всегда спрашивает, что стало хуже, и ждёт рассказа про согласованность данных, отладку цепочки вызовов и рост требований к инфраструктуре.
Приносят красивые цифры вроде ускорения разработки в разы без объяснения, как их измеряли. Аналитику такой ответ вредит сильнее всех: следующий вопрос будет про метрику и базу сравнения.