Как понять, что настал момент для распиливания монолита на микросервисы
Что проверяют
Умеете ли вы принимать архитектурное решение по признакам, а не по моде. Хороший ответ содержит и причины распилить, и причины этого не делать. Следом обычно спрашивают, с какого модуля вы бы начали и что будете делать с общей базой.
Как отвечать
Сильные признаки того, что пора:
- организационный: несколько команд мешают друг другу в одном репозитории, релиз требует согласования всех, а правка в одном модуле тянет полный регресс. Микросервисы в первую очередь решают именно это;
- разный профиль нагрузки: API на FastAPI или Django упирается в I/O, а рядом тяжёлая CPU-обработка. Их выгодно масштабировать отдельно;
- разные требования к надёжности: падение отчётов не должно ронять оплату;
- устоявшиеся границы: предметные области понятны и редко меняются, их можно описать как bounded context.
Слабые признаки, которые сами по себе ничего не доказывают: код стал медленным, файлы большие, «хочется новый стек». Медленный код лечится профилированием, а CPU-нагрузку в Python можно вынести в воркеры Celery или отдельные процессы без распила всей системы.
Разумный порядок: сначала модульный монолит с явными границами (зависимости между пакетами можно контролировать через import-linter), затем выделение по одному сервису по паттерну strangler fig. Инфраструктура готовится заранее: CI/CD на каждый сервис, контейнеры, централизованные логи и трассировка через OpenTelemetry.
Самое тяжёлое это данные. Общая база на всех превращает сервисы в распределённый монолит, а раздельные базы требуют саг и паттерна outbox вместо обычных транзакций.
Где спотыкаются
Говорят, что микросервисы упрощают отладку и тестирование. На деле наоборот: появляются сеть, частичные отказы, версии контрактов и поиск ошибки через десяток процессов.
Предлагают переписать всё разом. Переписывание с нуля обычно затягивается, а старый монолит тем временем продолжает меняться.
Выделяют сервисы по техническим слоям, например «сервис базы данных» и «сервис валидации». Делить нужно по бизнес-возможностям, иначе любое изменение задевает сразу несколько сервисов.