Есть ли опыт коллегиального решения по выделению микросервисов из монолита и как выбирали части для выделения
Что проверяют
Был ли у вас реальный опыт распила и понимаете ли вы, что граница сервиса это решение про данные и команды, а не про размер кода. Слово «коллегиальное» не случайно: интервьюеру важно, как вы спорили и договаривались. Следом почти всегда спрашивают, что стало с общей базой и транзакциями между сервисами.
Как отвечать
Каркас: зачем выделяли, как выбирали, как договорились, что получилось. Причина должна быть конкретной: независимые релизы, разная нагрузка, отдельная команда. «Монолит устарел» причиной не считается.
Критерии выбора первого кандидата:
- граница предметной области: bounded context из DDD, модуль со своей моделью данных и минимумом связей. Найти границы помогает event storming;
- частота изменений и нагрузка: часть, которую меняют каждую неделю или масштабируют отдельно, даёт выигрыш сразу;
- связность по данным: если модуль читает чужие таблицы, сначала разводите доступ через интерфейс внутри монолита и только потом выносите;
- риск: первым удобно брать некритичное, например уведомления или отчёты.
Техника: strangler fig, когда прокси или API-шлюз постепенно переводит маршруты на новый сервис. В Go это отдельный бинарник с gRPC или HTTP, события через Kafka или NATS, outbox для надёжной публикации. Внутри Go-монолита полезно сначала оформить модуль отдельным пакетом в internal/ с явным интерфейсом.
Коллегиальность покажите механикой: ADR с вариантами и аргументами, обсуждение RFC, пилот на одном модуле. Цифры только свои: сколько сервисов, за какой срок, как изменилось время релиза. Если распила не было, скажите честно и опишите, как выбрали бы границы в знакомом монолите.
Где спотыкаются
Режут по техническим слоям: «сервис базы», «сервис валидации». Получается распределённый монолит, где любая фича трогает все сервисы.
Оставляют одну базу на несколько сервисов. Независимого деплоя нет, миграции ломают соседей.
Не упоминают, что пошло плохо. Сильный ответ содержит хотя бы одну ошибку и вывод из неё.