Выбор архитектуры — это не технический вопрос, а бизнес-решение, которое определяет стоимость разработки, скорость вывода фич на рынок и бюджет на поддержку на годы вперёд. По нашему опыту, около 60% проектов страдают не от «неправильной» архитектуры, а от того, что она была выбрана без учёта стадии бизнеса: стартапы начинают с микросервисов и тонут в инфраструктуре, а растущие сервисы годами держатся на монолите, который уже не выдерживает нагрузку. В этой статье разберём оба подхода без хайпа, дадим алгоритм выбора под вашу ситуацию.
Что такое монолит и почему он до сих пор жив
Монолит — это приложение, где весь код (каталог, заказы, оплата, админка, рассылки) собран в одном проекте и развёрнут как единое целое. Это не «устаревший» подход, а рабочий инструмент: более 50% коммерческих систем в мире до сих пор работают на монолитной архитектуре — от интернет-магазинов на 10 000 заказов в день до внутренних CRM крупных компаний.Главное преимущество монолита — скорость. MVP на монолите команда из 2–3 разработчиков соберёт за 2–4 месяца. Все данные лежат в одной базе, нет сетевых задержек между сервисами, отладка занимает минуты, а не часы. Деплой один — один сбой затрагивает всё приложение, но и исправить его можно одним действием.
Что такое микросервисы на самом деле
Микросервисная архитектура — это разбиение системы на независимые сервисы (заказы, платежи, уведомления, аналитика), каждый со своей кодовой базой, базой данных и командой развертывания. Сервисы общаются через API и очереди сообщений. Отсюда ключевые плюсы: независимый релиз и масштабирование каждой части — можно усилить только модуль корзины перед распродажей, не трогая остальное.Но у этой свободы есть цена, и она часто недооценивается. Микросервисы требуют: настроенного CI/CD для каждого сервиса, контейнеризации (Docker, Kubernetes), централизованного логирования и мониторинга (Prometheus, Grafana, ELK), API Gateway, распределённой трассировки и обработки отказов. Это отдельная DevOps-компетенция, которой нет в большинстве команд из «двух сеньоров и джуна».
Когда монолит — правильный выбор
Монолит выигрывает на большинстве этапов жизни продукта. Берите его, если совпадает хотя бы 3–4 пункта из этого списка:- Команда до 8–10 разработчиков — координация через микросервисы будет стоить дороже, чем даст пользы;
- Стадия MVP или проверки гипотезы — скорость запуска важнее масштабируемости, которую, возможно, не понадобится;
- Нагрузка до ~5 000–10 000 одновременных пользователей — грамотный монолит + кеширование (Redis, CDN) справляется с этим без проблем;
- Ограниченный бюджет на инфраструктуру — один сервер/кластер против 6–10 машин под микросервисы: экономия 2–3 раза;
- Продуктовая логика ещё не устоялась — менять доменные границы в микросервисах крайне болезненно.
Когда микросервисы окупаются
Переход на микросервисы оправдан, когда боль от монолита становится измеримой в деньгах и часах простоя. Типичные триггеры:- Команда выросла до 15–20+ человек — релизы монолита начинают блокировать друг друга, время сборки превышает 30–40 минут;
- Разные модули требуют разного масштабирования — например, генерация отчётов грузит систему, а транзакционный core простаивает;
- Скорость релизов упала — каждая фича проходит через регресс всего приложения, релизы раз в 2–3 недели вместо ежедневных;
- Пиковые нагрузки непредсказуемы — маркетплейсы, билеты, распродажи: нужен независимый autoscaling критичных модулей;
- Бизнес разросся на несколько направлений — команды по продукту должны двигаться автономно.
Сколько это стоит: цифры, о которых молчат презентации
Реальный кейс: интернет-магазин с оборотом ~40 млн ₽/мес. Первая версия на монолите — 3,5 млн ₽ и 4 месяца. «Переезд» на микросервисы двумя годами позже — ещё 5–6 млн ₽ и 8–10 месяцев параллельной поддержки двух версий. Если бы архитектура закладывалась с запасом с первого дня, суммарные затраты были бы ниже на 30–40%.Обратная ситуация: стартап с бюджетом 1,5 млн ₽ начал сразу с микросервисов. На инфраструктуру и DevOps ушло 40% бюджета ещё до первой продажи, а до MVP добирались почти вдвое дольше запланированного. Деньги закончились раньше, чем продукт подтвердил спрос — классическая цена преждевременной оптимизации.
Золотая середина: модульный монолит
Для большинства проектов российского рынка оптимальный ответ — модульный монолит. Код физически остаётся одним приложением (со всеми плюсами простоты), но внутри жёстко разделён на доменные модули: заказы, платежи, клиенты, интеграции. Каждый модуль имеет собственные модели данных и общается с соседями через внутренние интерфейсы, а не через прямые запросы к чужим таблицам.Такой подход даёт «дешёвую страховку»: когда бизнес вырастет, модули можно по одному выносить в отдельные сервисы — начиная с самой нагруженной части (обычно это каталог или нотификации).
Алгоритм выбора: 5 вопросов перед стартом
Прежде чем утверждать архитектуру, ответьте на пять вопросов честно, в цифрах:- Какая нагрузка ожидается через 12 месяцев? Возьмите пессимистичный прогноз: пользователей, заказов, запросов в секунду. До 10 000 одновременных — монолита достаточно;
- Сколько разработчиков будет в команде через год? Меньше 10 — микросервисы создадут больше работы, чем снимут;
- Какой срок вывода продукта на рынок? Нужен запуск за 3–4 месяца — только монолит или модульный монолит;
- Есть ли в команде DevOps-компетенции? Kubernetes, мониторинг, очереди — если нет, закладывайте +1 специалиста в бюджет или выбирайте монолит;
- Насколько устоялась бизнес-логика? Если границы предметных областей ещё «плывут», фиксировать их в микросервисах рано.
Три ошибки, которые дорого обходятся
Практика показывает типичные провалы, которых легко избежать:- Распределённый монолит — сервисы формально разделены, но синхронно завязаны друг на друга через цепочки API-вызовов: падение одного роняет всю цепочку, а деплой требует одновременного релиза всех. Это худшее из двух миров;
- Отказ от проектирования в монолите — «потом перепишем» почти никогда не работает: спагетти-код без модульных границ разбирать дороже, чем строить заново. Модульность закладывайте с первого дня даже в самом маленьком проекте.
Итог: архитектура — это про стадию бизнеса, а не про моду. Начинайте с модульного монолита, если у вас команда до 10 человек, срок запуска важнее масштаба и бюджет на инфраструктуру ограничен — это покрывает потребности 80% проектов. Переходите к микросервисам, когда измеримая боль появится: релизы тормозят, нагрузка бьёт по конкретным модулям, команда переросла 15 человек. Если сомневаетесь — заказывайте технический аудит или проектирование архитектуры на старте: 150–300 тысяч ₽ за проработку решения экономят миллионы на переписывании через два года.