Есть ли опыт коллегиального решения по выделению микросервисов из монолита и как выбирали части для выделения

Что проверяют

Умеете ли вы принимать архитектурное решение вместе с командой и обосновывать его критериями, а не модой на микросервисы. Интервьюеру важно, какую роль играли вы и на чём строился выбор. Следом обычно спрашивают, как разделили данные и что пошло не так.

Как отвечать

Стройте ответ на своём случае: какой был монолит (Django, Flask, FastAPI), какую боль решали, кто участвовал в обсуждении и как фиксировали решение. Затем назовите критерии выбора:

• границы предметной области: модуль с понятным bounded context и своими данными, например биллинг, уведомления, поиск. Хорошие кандидаты часто совпадают с Django-приложениями, которые не лезут в модели друг друга;
• связность по коду и данным: граф импортов через pydeps, проверка границ через import-linter, список таблиц, которые модуль читает и пишет. Общие таблицы это главный тормоз разделения;
• разный профиль нагрузки или релизов: часть, которую нужно масштабировать отдельно или выкатывать чаще остальных;
• владелец: у сервиса должна быть команда, иначе он станет ничьим.

Процесс обычно такой: обсуждение на архитектурном ревью или через RFC, решение фиксируется в ADR, выделение идёт по схеме «душитель» с маршрутизацией перед монолитом. Синхронные вызовы через HTTP или gRPC, события через Kafka или RabbitMQ, согласованность данных через transactional outbox.

Цифры результата называйте только свои и проверяемые: время релиза, число инцидентов, время сборки. Если опыта выделения нет, скажите прямо и расскажите, как подошли бы к задаче на знакомом монолите, или о модуляризации внутри одного репозитория.

Где спотыкаются

Режут по техническим слоям («сервис моделей», «сервис API») вместо предметных областей. Получается распределённый монолит, где любая фича трогает три сервиса.

Оставляют общую базу на всех. Сервисы формально разные, но выкатываются согласованно и ломаются вместе.

Не называют цену: сетевые задержки, распределённые транзакции, трассировка, отдельный CI для каждого сервиса. Без этого ответ звучит как пересказ статьи, а не как опыт.