Монолит vs микросервисы для бизнеса: как выбрать без моды

Введение. Спор «монолит vs микросервисы» в 2026 году решается не религией, а скоростью поставки ценности и стоимостью сопровождения. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Бизнес-контекст выбора архитектуры

Большинство срывов в теме «монолит и микросервисы» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

Команды, которые режут монолит на сервисы раньше, чем стабилизировались доменные границы, теряют 20–40% спринтов на синхронизацию контрактов между сервисами — вместо фич инженеры чинят breaking changes API, которые в монолите закрылись бы одним PR.

Trade-offs: скорость vs гибкость

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте Kubernetes и модель данных. Для монолит и микросервисы мы обычно рекомендуем модульный монолит с явными bounded context и контрактами между модулями: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. микросервисы имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

Наблюдаемость — статья расходов, которую недооценивают при разрезании на сервисы: distributed tracing, корреляция request_id между сервисами, единый дашборд latency и error rate по каждому из них. Без этого инцидент P1 расследуют часами вместо минут — посчитайте эту стоимость до перехода на микросервисы, а не после.

Когда хватает простого контура

Кейс A (оптовая дистрибуция). Клиент пришёл с болью: заказы «зависали» между складом и 1С, а nightly batch ломал отчёты. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель latency оформления заказа снизился с 4,2 до 0,9 с без полного разрезания монолита. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (маркетплейс услуг). Другая ситуация: разные команды деплоили общую БД и ломали соседние фичи. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: после выделения каталога и биллинга в сервисы частота инцидентов P1 упала в 3 раза.

Когда нужна более сложная схема

1. Выбор микросервисов ради резюме команды, а не под реальный профиль нагрузки.
2. Разрезание по техническим слоям (все API в одном сервисе, вся логика в другом) вместо доменных границ.
3. Общая база данных на несколько сервисов — распределённый монолит с виду микросервисов.
4. Отсутствие бюджета на DevOps и on-call при переходе на распределённую систему.
5. Big bang миграция без strangler-паттерна и промежуточных контрактов событий.

Как мигрировать без простоя

• [ ] Определён первый модуль для выноса по strangler-паттерну
• [ ] Зафиксированы контракты событий между монолитом и новым сервисом
• [ ] Посчитана стоимость observability и on-call для распределённой системы
• [ ] Настроены feature flags для отката на каждом шаге миграции
• [ ] Бизнес-метрики, а не только технические, сравниваются до и после выноса
• [ ] Определены критерии успеха: lead time, change fail rate, MTTR

Практический вывод

Микросервисы покупают организационную автономию и независимые релизы, но требуют зрелого DevOps. Монолит остаётся лучшим стартом, если домен ещё меняется каждый квартал. Если нужна внешняя экспертиза — начните с брифа или оценки: так быстрее получить реалистичный план, чем спорить о стеке в вакууме.

• До 15 инженеров и один продукт — чаще модульный монолит
• Разные SLA для подсистем — кандидат на выделение сервиса
• Считайте стоимость observability и on-call до разрезания

Критерии решения для бизнеса

Сравнивайте не «модно / не модно», а три числа: частота релизов, MTTR и стоимость инцидента. Если продукт один и команда до 12–15 человек, модульный монолит на PostgreSQL с чёткими пакетами домена почти всегда дешевле, чем сеть из восьми сервисов с частичным падением корзины. Микросервисы оправданы, когда разные части системы имеют разный профиль нагрузки (каталог vs биллинг), разные команды с отдельными OKR или регуляторные границы (PII, платежи). Перед разрезанием зафиксируйте strangler-fig: какой модуль выносите первым, какие контракты событий и как откатываетесь, если новый сервис не выдерживает пик.

Миграция «big bang» с монолита редко удаётся. Рабочая схема: вынести read-модели и отчётность, затем интеграционный слой с 1С или CRM, и только потом транзакционное ядро. На каждом шаге — feature flag, синтетические проверки критичных сценариев и сравнение бизнес-метрик до/после. Если после выноса сервиса time-to-deploy команды не улучшился за два квартала, возможно, проблема была в процессе, а не в монолите.