Микросервисы продали как панацею. Но за гибкость платится сложностью: distributed tracing, message brokers, eventual consistency, service mesh, deployment pipelines на каждый сервис. Для большой команды на большом продукте — это окупается. Для средней — обычно нет.
Когда микросервисы реально нужны
По нашему опыту — три кейса:
- Большая команда (50+ разработчиков), которая физически не может работать на одном репозитории без блокировок.
- Разные SLA для разных частей системы. Например: каталог должен выдерживать 10000 RPS, а админка — 5 RPS. Имеет смысл вынести каталог в отдельный сервис со своим горизонтальным масштабированием.
- Разные стеки. Например, ML-сервис на Python, фронт-API на Go. Микросервис — естественная граница.
Когда монолит лучше
Если у вас 5–15 разработчиков, единые SLA и единый стек — монолит обычно выигрывает по всем метрикам: время разработки, надёжность, операционная нагрузка, стоимость инфраструктуры. И главное — латентность транзакций, которые в микросервисах развалятся на 5–10 HTTP-запросов с разными ошибками в каждом.
«Модульный монолит» — компромисс
Если есть подозрение что когда-нибудь придётся пилить на сервисы — можно сразу строить монолит с жёсткими границами модулей. Каждый модуль:
- Имеет публичное API (Python: класс с методами; Java: interface).
- Не лезет в чужие таблицы напрямую — только через API владельца таблицы.
- Тестируется изолированно.
В итоге у вас один процесс, одна база, простой деплой — но если завтра понадобится вынести модуль в отдельный сервис, граница уже есть.
Реальный пример
На одном из наших проектов (e-commerce, 80 разработчиков клиента) мы делали аудит архитектуры. У них была классическая «спагетти-микросервисная» система из 47 сервисов. После аудита рекомендовали склеить 30 из них обратно в три модульных монолита. Через полгода клиент сообщил: время доставки фич выросло в 2 раза, операционная нагрузка упала на 60%.
Как принять решение
Спросите себя: «Если бы мы начали проект сегодня — мы бы сразу делали микросервисы?» Если ответ «нет, потому что нас всего 7 разработчиков» — то и сейчас они вам не нужны. Если «да, потому что у нас отдельные команды на каждый домен и разные SLA» — тогда нужны.
Правило простое: не идите в микросервисы, пока боль монолита не станет дороже боли распределённой системы.
