Микросервисы для маркетплейса: когда это необходимость, а когда — лишние миллионы
«Давайте сразу на микросервисах — так масштабируемся». Фраза звучит разумно, пока не приходит смета: вместо MVP за 4 месяца — год проектирования, три команды DevOps и релизы, которые ломают соседний сервис.
Для маркетплейса микросервисы — не признак «взрослости». Это дорогой инструмент, который окупается только при конкретных ограничениях: нагрузка, скорость изменений, несколько команд. Во всех остальных случаях вы платите за сложность, которую ещё не заработали.
Главное. Микросервисы на старте маркетплейса — почти всегда лишние деньги. Сначала модульный монолит, кеш и пик по горячим путям. Дробить — когда команды и нагрузка уже упёрлись в один релиз.
Почему тема болит именно у маркетплейсов
Маркетплейс — это сразу несколько «продуктов» в одном: витрина для покупателя, кабинет продавца, платежи, поиск, модерация, аналитика. Кажется логичным «разрезать» это на сервисы с первого дня. Но на практике 80% новых площадок ещё не упёрлись в те проблемы, ради которых микросервисы и придумали.
Типичный сценарий: стартап закладывает 15–20 сервисов, Kubernetes и event bus до первой тысячи заказов. Через полгода команда тратит больше времени на согласование релизов и отладку сетевых вызовов, чем на функции, которые приносят GMV.
Что на самом деле решают микросервисы
Не «скорость сайта» и не «масштаб как у Wildberries». Они решают три управленческие задачи:
- Независимые релизы — каталог можно обновлять, не трогая платежи.
- Точечное масштабирование — поиск крутится на 10 инстансах, админка — на одном.
- Разные команды — три squad'а не мешают друг другу в одном репозитории.
Если у вас одна команда из 3–8 человек и один релиз в две недели — эти задачи закрывает модульный монолит с чёткими границами внутри кода. Дешевле в 2–3 раза на старте и проще менять архитектуру, пока бизнес-модель ещё плавает.
5 сигналов: пора выносить части в отдельные сервисы
- Релиз занимает недели — любое изменение в поиске требует регресса всего монолита
- Разные части растут по-разному — поиск и каталог грузят CPU, а админка простаивает, но масштабируется вместе с ними
- 2+ команд работают параллельно — постоянные конфликты в одном репозитории и «очередь на деплой»
- Падение одного модуля валит всё — ошибка в генерации PDF-накладных кладёт оформление заказа
- Есть измеримый узкий горлышко — нагрузочный тест показал: 90% задержки в одном компоненте, остальное простаивает
Если совпало два и больше пункта — имеет смысл планировать вынос одного горячего модуля (часто поиск, платежи или уведомления), а не «переписать всё».
4 признака, что микросервисы сейчас — лишние траты
- Нет продаж / GMV на горизонте 12 месяцев — вы оптимизируете инфраструктуру будущего, а не продукт настоящего.
- Команда меньше 10 инженеров — overhead на DevOps, мониторинг и контракты между сервисами съест выгоду.
- Бизнес-модель меняется каждый квартал — жёсткие границы сервисов будете перекраивать дороже, чем модули в монолите.
- «Хотим как у больших» — у крупных маркетплейсов микросервисы появились после боли монолита, а не до первого заказа.
Сколько это стоит — грубая математика
Оценка для маркетплейса MVP (каталог, заказы, продавцы, платежи, admin):
| Подход | Срок до первых продаж | Ориентир бюджета |
|---|---|---|
| Модульный монолит | 2–4 мес. | от 800 000 ₽ |
| Микросервисы «с нуля» | 6–12 мес. | от 2,5–4 млн ₽ |
| Переделка монолита в микросервисы без подготовки | +4–8 мес. к текущему | часто ×1,5–2 к «чистой» разработке |
* диапазоны для типового B2B-маркетплейса; интеграции и дизайн могут сдвинуть цифры
Разница — не только в разработке. Микросервисы требуют наблюдаемости, CI/CD на каждый сервис, runbooks и дежурств. Это +60 000–160 000 ₽/мес на поддержку против одного аккуратно собранного монолита.
Рабочая стратегия: Strangler Fig для маркетплейса
Не «монолит vs микросервисы», а поэтапный вынос — паттерн, который используют зрелые команды:
Так вы не «переписываете Ozon», а покупаете масштаб по мере появления денег, а не авансом.
Антипаттерн: распределённый монолит
Худший исход — 12 микросервисов, которые синхронно дергают друг друга, делят одну базу и падают цепочкой. Вы платите за сложность микросервисов, но получаете минусы монолита: долгий регресс, неясные зависимости, страх трогать код.
Признаки у CTO на ревью архитектуры:
- Один пользовательский клик = 5+ синхронных HTTP-вызовов между сервисами
- Несколько сервисов пишут в одни таблицы
- «Временно» общая библиотека с бизнес-логикой на все сервисы
- Нет метрик по каждому сервису — только «сайт тормозит»
Чеклист для совещания с CTO / подрядчиком
- Какой GMV и RPS мы планируем через 12 месяцев — цифра, не «много пользователей»
- Сколько инженерных команд будет параллельно через год
- Какой модуль первым упирается в потолок по нагрузочному тесту
- Можем ли мы описать границы модулей в монолите до дробления
- Есть ли бюджет на observability и on-call после запуска
- Что будет дешевле: вынести один сервис или оптимизировать монолит (кэш, индексы, очереди)
- Кто владеет данными при сплите — схема до начала разработки
Главное
Микросервисы для маркетплейса — не цель и не статус. Это ответ на измеримую боль: медленные релизы, узкое горлышко, несколько команд. На старте чаще выигрывает модульный монолит с запасом по архитектуре и планом поэтапного выноса.
Мы в NineLab проектируем маркетплейсы так: сначала — работающие продажи и понятный бюджет, потом — масштабирование там, где цифры показывают узкое место, а не там, где модно на конференции.
Что дальше
Разберём вашу нагрузку и узкие места: high-load под ключ, нагрузочное тестирование или квиз оценки за 2 минуты.
Сервисы и материалы по теме
Микросервисы для маркетплейса — вопросы
Когда одна команда уже не успевает релизить монолит, пик упирается в разные контуры (каталог ≠ оплата ≠ поиск) и цена простоя высока. На старте MVP «как у Ozon» почти всегда лишние миллионы.
Год проектирования вместо MVP за 4 месяца, отдельный DevOps на каждый сервис, каскадные поломки на релизе. Платите за сложность, которую ещё не заработали нагрузкой.
Нет, если его режут по модулям, кешируют и масштабируют чтение. Опасен «большой ком» без границ и тестов. Микросервисы не лечат плохую модель данных.
Вынести самый горячий контур (поиск, корзина, платежи), не дробить всё. Сначала метрики и стресс-тест, потом границы сервисов.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Как мы готовим проект к HighLoad: взгляд на систему до пика
Метод NineLab: как смотрим на проект перед HighLoad — цель нагрузки, модель пика, карта узких мест, порядок правок и проверка стресс-тестом до рекламы.
Читать статьюЛК клиента B2B: MVP из 7 экранов, которые реально открывают
Личный кабинет клиента B2B: какие 7 экранов нужны в MVP, что отложить на v2, ориентир сроков и бюджета и чеклист приёмки для дилерского / партнёрского портала.
Читать статьюКак мы сделали поиск организаций для asknayda.ru: лексика, ИИ и пилот
Как устроен поиск компаний в Найде (asknayda.ru): OpenSearch, модель bge-m3, когда включается семантический слой, RRF-гибрид и стадия пилота продукта.
Читать статьюSEO больше не хватит: магазину нужны API под ИИ-агентов
SEO находит клиента, API даёт ИИ-агенту купить. OpenAPI для e-commerce и МСБ: чеклист контура, риски в ₽ и рамка «когда пора».
Читать статью