Микросервисы для маркетплейса: когда это необходимость, а когда — лишние миллионы
«Давайте сразу на микросервисах — так масштабируемся». Фраза звучит разумно, пока не приходит смета: вместо 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 проектируем маркетплейсы так: сначала — работающие продажи и понятный бюджет, потом — масштабирование там, где цифры показывают узкое место, а не там, где модно на конференции.
Сервисы и материалы по теме
Частые вопросы по теме
Профиль трафика и данные на стенде редко совпадают с боем. Нужны сценарии, те же метрики, что в проде, и поэтапное наращивание с возможностью отката.
Часто первыми «краснеют» база и планы запросов, пулы соединений, синхронные вызовы внешних API и очереди — это даёт быстрый чек-лист проверки.
Не обязательно: инвалидация, холодный старт и неравномерность ключей могут навредить. Кэш проектируют под конкретные read-модели и SLO.
Когда вертикальное масштабирование и оптимизация запросов упёрлись в потолок, а рост данных предсказуем по ключу партиционирования.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Redis, очереди и кэширование: как сделать сайт в 10 раз быстрее без покупки нового железа
Разбираем, почему сайт тормозит при «нормальном» сервере, что кешировать в Redis, какие задачи уводить в очереди, когда подключать CDN — и какие цифры ждать после оптимизации без роста счёта за хостинг.
Читать статьюСколько стоит 1 час простоя вашего сайта: считаем на конкретных примерах
Формула расчёта стоимости простоя для e-commerce, B2B и SaaS: прямые и скрытые потери, коэффициент пика и чеклист подготовки к инцидентам. С привязкой к реальным сбоям инфраструктуры в 2026 году.
Читать статьюРеклама на 10 миллионов и ошибка 503: как техническая неготовность сжигает маркетинговые бюджеты
Разбираем, почему рекламные кампании сгорают из-за упавшего сайта: считаем реальные потери, объясняем три системные причины и даём чеклист подготовки инфраструктуры перед крупным запуском.
Читать статьюExcel больше не справляется: 5 звоночков, что вашему бизнесу пора разработать кастомное приложение
Признаки, что бизнес «вырос из таблиц»: ошибки в учёте, ручные согласования, потеря заявок и отсутствие прозрачности. Разбираем, когда пора переходить к автоматизации бизнес‑процессов и разработке внутреннего веб‑приложения (портала, личного кабинета, системы заявок) под ваши реальные процессы.
Читать статью