Как устроена архитектура маркетплейса

По данным Data Insight за 2025 год, на маркетплейсы приходится 81% всех онлайн-заказов и 62% объёма онлайн-продаж в России; рынок e-commerce вырос до 13,4 трлн рублей (+19% год к году). По оценке АКИТ, которую приводит Forbes, объём интернет-торговли достиг 11,5 трлн рублей. Маркетплейсы доминируют — и именно поэтому вопрос архитектуры маркетплейс-платформы стал одним из самых обсуждаемых в продуктовой разработке.

Распространённое заблуждение: маркетплейс — это «интернет-магазин, но побольше». Это не так. Маркетплейс — трёхсторонняя платформа с принципиально иной архитектурой: покупатель, продавец и оператор существуют в одной системе, и каждая сторона предъявляет свои требования к надёжности, изоляции данных и финансовым операциям. В этой статье разберём, как устроена архитектура маркетплейса изнутри — из каких подсистем она состоит, какие архитектурные развилки проходит команда от MVP до высоконагруженной платформы и где чаще всего ломается.

Содержание

Маркетплейс с точки зрения архитектуры: три стороны и их сценарии

Любой маркетплейс обслуживает три группы пользователей одновременно, и каждая из них генерирует принципиально разные сценарии использования.

Покупатель взаимодействует с каталогом, поиском, корзиной, оформлением заказа, отслеживанием доставки и отзывами. Для него важны скорость загрузки, точность поиска и надёжность оплаты. Продавец (мерчант) управляет своим ассортиментом, ценами, остатками, обрабатывает поступившие заказы и следит за своим рейтингом. Для него критичны инструменты самообслуживания, прозрачность комиссий и своевременные выплаты. Оператор платформы модерирует контент, разрешает споры, управляет комиссионной политикой, следит за антифродом и анализирует данные всей платформы.

Чем архитектура маркетплейса принципиально отличается от обычного интернет-магазина? Три главных отличия:

• Мультивендорность. Тысячи продавцов с независимыми каталогами, ценами и остатками. Это требует надёжной изоляции данных между мерчантами (мультиарендность) и сложной логики дедупликации товаров.
• Финансовые расчёты с продавцами. Деньги покупателя проходят через эскроу-счёт платформы и должны быть корректно разделены между продавцами и платформой — с учётом возвратов, споров и комиссий. Ошибка здесь стоит реальных денег.
• Модерация и доверие. Платформа отвечает за качество всего контента — описаний, фото, цен — который создают тысячи продавцов с разным уровнем добросовестности.

Из каких подсистем состоит маркетплейс

Структура маркетплейса — это набор взаимосвязанных доменов, каждый из которых решает свою задачу. Разберём ключевые из них.

Каталог и карточки товаров

Каталог маркетплейса принципиально сложнее, чем у монобренда: у тысяч продавцов могут быть «одинаковые» товары (одна модель смартфона от разных мерчантов), и платформа должна уметь дедуплицировать SKU, объединять предложения и управлять канонической карточкой товара. Для этого используется PIM-система (Product Information Management) — либо сторонняя, либо собственная разработка.

Атрибутная модель должна быть гибкой: у ноутбука и у платья совершенно разные характеристики. Реализуют это через EAV-структуры (Entity-Attribute-Value) или хранение атрибутов в JSONB-полях PostgreSQL с отдельным индексированием. Категорийное дерево — отдельная сущность с поддержкой смены категории товара без потери истории.

Поиск, фильтры и рекомендации

Поиск через SQL LIKE — одна из главных архитектурных ошибок маркетплейса, которая обнаруживается только под нагрузкой. На любой серьёзной платформе поиск выносится в отдельный поисковый движок: Elasticsearch или OpenSearch. Они обеспечивают полнотекстовый поиск с морфологией, фасетные фильтры (по атрибутам) и гибкое ранжирование.

Ранжирование результатов — отдельная задача: нужно балансировать между релевантностью запроса, рейтингом продавца, ценой, скоростью доставки и коммерческими интересами платформы (платное продвижение). Персонализация рекомендаций (блок «с этим товаром покупают») — ещё один независимый компонент, который подключается позже, когда накопится достаточно данных о поведении пользователей.

Корзина и оформление заказа

Корзина маркетплейса содержит товары от разных продавцов одновременно, и при оформлении checkout должен разбить её на отдельные субзаказы — по одному на каждого мерчанта. Каждый субзаказ имеет свои условия доставки, свою стоимость и свой статус обработки. Это называется split-корзиной, и её корректная реализация — нетривиальная задача особенно в части расчёта итоговой суммы с промокодами и скидками, которые могут применяться на разных уровнях.

Состояние корзины хранят в Redis (быстрый кэш для анонимных и авторизованных сессий), а при переходе к оплате — фиксируют в основной БД.

Кабинет продавца и модерация контента

Seller-кабинет — это фактически отдельное мини-приложение внутри платформы: управление ассортиментом, загрузка прайс-листов (XLS/CSV/XML), настройка акций, просмотр аналитики, работа с заказами. Часто его разрабатывают как самостоятельный фронтенд (SPA на React/Vue), обращающийся к специализированному API.

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

Управление заказами, логистика и фулфилмент

Система управления заказами (OMS — Order Management System) отвечает за весь жизненный цикл заказа: от оформления до доставки и возможного возврата. Это одна из наиболее сложных подсистем, поскольку заказ проходит через несколько независимых систем: платёжный процессор, склад или мерчант, служба доставки.

Интеграции с логистическими операторами (СДЭК, Почта России, DHL, маркетплейсовые пункты выдачи) строятся через их API: создание накладных, трекинг, возвраты. Статусы заказа синхронизируются через вебхуки или периодический polling. Важно проектировать OMS так, чтобы он мог работать в условиях временной недоступности службы доставки — через очереди и retry-механизмы.

Платежи, эскроу и выплаты продавцам

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

1. Покупатель оплачивает заказ — деньги поступают на технический счёт платформы через эквайринг (Stripe, ЮКасса, Тинькофф Бизнес и др.).
2. Деньги холдируются (эскроу) до подтверждения получения заказа покупателем.
3. После подтверждения платформа выполняет сплит-платёж: удерживает комиссию (например, 5–15%), переводит остаток продавцу.
4. При возврате — обратная операция с учётом уже переведённых средств.

Критическое требование — идемпотентность всех финансовых операций. Каждый запрос к платёжному API должен содержать уникальный ключ идемпотентности, чтобы при сетевом сбое, таймауте или retry деньги не списались дважды. Паттерн описан в microservices.io (Chris Richardson) — Saga для координации распределённых транзакций и Outbox Pattern для надёжной публикации событий.

Выплаты продавцам выполняются по расписанию (раз в неделю или по достижении порога) через банковский API или платёжный агрегатор. Эта подсистема попадает под требования PCI DSS, что накладывает ограничения на хранение данных карт — их не хранят в собственной БД, а токенизируют через провайдера эквайринга.

Отзывы, рейтинги, антифрод и репутация

Рейтинговая система должна быть устойчива к накрутке: проверять, что отзыв оставляет реальный покупатель конкретного товара у конкретного продавца, фильтровать аномальный рост рейтинга, детектировать подозрительные поведенческие паттерны (массовые отзывы с одного IP, аккаунты-фантомы). Антифрод реализуется как отдельный сервис с ML-моделями или через интеграцию со специализированными системами (Signifyd, SEON и аналогами).

Монолит или микросервисы: как выбрать под стадию

Распространённое заблуждение — начинать маркетплейс сразу с микросервисной архитектуры. На старте это почти всегда проигрышная стратегия.

Модульный монолит — лучший выбор для MVP. Это хорошо структурированное монолитное приложение с чёткими границами между доменами (каталог, заказы, платежи, пользователи). Границы соблюдаются на уровне кода (отдельные модули/пакеты с инверсией зависимостей), но деплой единый. Такой подход:

• ускоряет первоначальную разработку в 2–3 раза по сравнению с распределённой системой;
• упрощает отладку (один процесс, один стектрейс);
• сохраняет возможность выделить сервис позже без полного переписывания — границы уже обозначены.

Когда имеет смысл выделять микросервисы? Только при наличии конкретных метрик:

• Конкретный модуль стал узким местом по нагрузке (каталог, поиск) и его нужно масштабировать независимо от остальной системы.
• Разные команды работают над разными доменами и мешают друг другу при деплое.
• Модуль требует другого технологического стека (например, поиск на Elasticsearch, ML-рекомендации на Python).
• Требования надёжности к модулю (финансы, платежи) значительно выше, чем к остальной системе.

Цена преждевременного дробления высока: операционная сложность резко возрастает (оркестрация, service discovery, распределённая трассировка), каждый межсервисный вызов добавляет латентность и точку отказа, транзакционность между сервисами пропадает по умолчанию — её нужно восстанавливать через паттерны Saga. Многие команды после года работы с «микросервисами для стартапа» возвращались к модульному монолиту.

Событийная архитектура и асинхронность

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

Решение — событийная (event-driven) архитектура: когда заказ оформлен, система публикует событие OrderCreated в брокер сообщений (Kafka или RabbitMQ), и каждый заинтересованный сервис обрабатывает его независимо в своём темпе. Это даёт:

• Слабую связанность. Сервисы не знают друг о друге напрямую — только о событиях.
• Отказоустойчивость. Если сервис уведомлений недоступен — событие остаётся в очереди и будет обработано при восстановлении.
• Масштабируемость. Потребители очереди масштабируются горизонтально под нагрузку.

Для распределённых транзакций (заказ → оплата → резерв склада → доставка) применяется паттерн Saga — последовательность локальных транзакций с компенсирующими действиями при сбое. Если оплата прошла, но склад не смог зарезервировать товар — Saga откатывает оплату. Важно помнить: это eventual consistency, а не строгая транзакционность — система в конечном счёте придёт в согласованное состояние, но не мгновенно.

Для надёжной публикации событий используется паттерн Transactional Outbox: событие сохраняется в ту же транзакцию, что и бизнес-запись в БД, а отдельный компонент (relay) читает outbox-таблицу и публикует события в брокер. Это исключает потерю событий при сбое между записью в БД и публикацией в Kafka.

Данные маркетплейса: где что хранить

Архитектура данных маркетплейса — это не «выбрать одну СУБД», а осознанное распределение данных по специализированным хранилищам.

Тип данных	Хранилище	Почему
Заказы, транзакции, пользователи	PostgreSQL	ACID, целостность, Foreign Keys
Каталог с полнотекстовым поиском	Elasticsearch / OpenSearch	Быстрый full-text, фасеты, ранжирование
Сессии, корзины, счётчики, кэш	Redis	Sub-millisecond latency, TTL
Изображения, документы	Object Storage (S3-совместимое) + CDN	Дешёвое хранение, глобальная раздача
Аналитика, логи событий	ClickHouse / BigQuery	Колончатая, быстрые агрегации на больших объёмах

Часто требуется разделение чтения и записи (CQRS): транзакции записи идут в мастер-базу, читающие запросы — в реплики или в специализированный read-store. Это позволяет масштабировать читающую нагрузку (которая на маркетплейсе значительно превышает записывающую) независимо.

Для синхронизации данных между системами применяется CDC (Change Data Capture): изменения в PostgreSQL через Debezium публикуются в Kafka и реплицируются в Elasticsearch (каталог) или аналитическую БД. Это исключает двойную запись и обеспечивает консистентность между разными хранилищами.

API и интеграции

Внешний API маркетплейса — это набор контрактов для трёх групп клиентов: браузерных приложений, мобильных клиентов и продавцов. Как правило, архитектура строится вокруг API Gateway — единой точки входа, которая маршрутизирует запросы, обеспечивает аутентификацию, rate limiting и логирование.

Выбор между REST и GraphQL зависит от клиентских требований. REST проще кэшировать и легче тестировать; GraphQL позволяет клиентам запрашивать ровно те поля, которые нужны — что особенно ценно на мобильных клиентах с ограниченным трафиком. Многие платформы используют GraphQL для потребительского фронтенда и REST для партнёрских API продавцов.

Открытый API для продавцов (seller API) позволяет мерчантам автоматизировать управление каталогом, синхронизировать остатки из своих ERP-систем и получать уведомления о заказах через вебхуки. Вебхуки — более эффективный механизм, чем polling: платформа сама уведомляет продавца при изменении статуса заказа.

Типовые внешние интеграции маркетплейса:

• 1С и ERP-системы продавцов — синхронизация остатков, прайс-листов, заказов через комплексный обмен или прямой API.
• Платёжные шлюзы — ЮКасса, Тинькофф, СБП, при международной работе Stripe/Adyen.
• Логистические операторы — СДЭК, Почта России, Boxberry, DPD: создание накладных, трекинг, печать этикеток.
• Антифрод-системы — проверка транзакций и аккаунтов на мошенничество.
• Аналитические платформы — передача событий в GA4, Яндекс.Метрику, BI-системы.

Если платформа интегрируется с множеством внешних систем, стоит рассмотреть профессиональную системную интеграцию — она снижает риски при подключении 1С, ERP и платёжных провайдеров.

Масштабирование и высокие нагрузки

Маркетплейс по природе своей — высоконагруженная система: тысячи одновременных пользователей в обычный день и десятки тысяч в период акций. Архитектура маркетплейса должна это учитывать с самого начала — не в смысле «сразу строить под миллион RPS», а в смысле «не принимать решений, которые заблокируют масштабирование».

Ключевые принципы масштабирования:

• Горизонтальное масштабирование. Stateless-сервисы запускаются в нескольких инстансах за балансировщиком нагрузки (Nginx, HAProxy, облачный ALB). Сессионные данные — в Redis, не в памяти приложения.
• Кэш-стратегия. Каталог меняется редко — агрессивно кэшируем в Redis с инвалидацией при изменении. CDN кэширует статику и медиа. HTTP-кэш на уровне заголовков для read-only страниц.
• Шардирование БД. При росте таблицы заказов или транзакций за разумные пределы — шардирование по продавцу или временному диапазону. PostgreSQL поддерживает партиционирование нативно.
• Подготовка к распродажам. За несколько часов до акции: прогрев кэша по популярным товарам, проверка и временное увеличение capacity, включение rate limiting на checkout, идемпотентность корзины и оплаты на случай retry от клиента.

Идемпотентность — особый акцент. Под нагрузкой сетевые сбои и таймауты — норма. Если добавление в корзину, оформление заказа и особенно оплата не идемпотентны, пользователи получат дублированные заказы и двойные списания. Каждый write-запрос должен принимать idempotency-key от клиента и возвращать один и тот же результат при повторном вызове.

Безопасность и отказоустойчивость

Безопасность маркетплейса — многоуровневая задача, затрагивающая сразу несколько доменов.

PCI DSS — если платформа принимает банковские карты напрямую, она попадает в область действия стандарта. На практике большинство маркетплейсов минимизирует свою PCI-область через токенизацию: данные карты никогда не касаются серверов платформы, а проходят через iframe или JS-виджет эквайринга. Токен хранится в БД и используется для повторных платежей.

Мультиарендность и изоляция данных. Продавец А не должен видеть данные продавца Б. Это обеспечивается на нескольких уровнях: Row-Level Security в PostgreSQL, обязательная фильтрация по merchant_id в каждом запросе, изоляция хранилищ медиа (отдельные S3-бакеты или префиксы), аудит-логи всех операций с чужими данными.

Отказоустойчивость и деградация. Архитектура маркетплейса должна поддерживать работу в условиях частичной недоступности компонентов. Если сервис рекомендаций недоступен — страница товара должна отображаться без блока «похожие товары», а не выдавать 500. Паттерны Circuit Breaker (размыкание цепи при каскадных ошибках) и Fallback (запасное поведение) реализуются через Resilience4j, Istio или на уровне API Gateway.

Резервное копирование и восстановление: финансовые данные и заказы — WAL-репликация PostgreSQL на standby, Point-in-Time Recovery (PITR), регулярные тесты восстановления. RPO (допустимая потеря данных) для финансовой части — секунды, RTO (время восстановления) — минуты.

Типичные ошибки в архитектуре маркетплейса

Большинство проблем, с которыми сталкиваются растущие маркетплейсы, предсказуемы. Вот самые распространённые:

• Одна реляционная БД под всё. PostgreSQL отлично справляется с транзакциями и заказами — но поиск по каталогу через LIKE и аналитические агрегации убивают производительность при масштабировании. Проектируйте полиглотное хранение сразу.
• Синхронные вызовы в критичном пути. Если checkout ждёт ответа от уведомительного сервиса — один downtime уронит весь процесс оформления заказов. Нетранзакционные операции (уведомления, аналитика, обновление рейтингов) выносите в асинхронные очереди.
• Отсутствие идемпотентности платежей. Под нагрузкой клиент нажимает «оплатить» несколько раз или запрос timeout'ится и повторяется. Без idempotency-key результат — дублированные транзакции.
• «Микросервисы ради микросервисов». Начать с 20 сервисов на старте без чёткого понимания границ доменов — быстрый путь к «распределённому монолиту», где всё равно всё связано синхронными вызовами, но при этом крайне сложно дебажить.
• Поиск через LIKE в основной БД. Работает на тысяче товаров. Ломается на ста тысячах. Elasticsearch — не опция, а базовое требование для каталога маркетплейса с ростом ассортимента.
• Нет плана на пики нагрузки. Распродажа приходит как сюрприз, хотя дата известна заранее. Отсутствие load testing, прогрева кэша и дополнительной capacity = даунтайм в самый горячий момент.

С чего начать: MVP-архитектура и эволюция

Для большинства маркетплейсов оптимальная стартовая точка — модульный монолит плюс управляемые внешние сервисы.

Что стоит взять готовым с самого начала:

• Эквайринг — ЮКасса, Тинькофф или Stripe уже решают PCI DSS, эскроу (через холдирование) и выплаты продавцам через сплит-платёж. Не строить свою платёжную инфраструктуру на MVP.
• Поиск — Elasticsearch или облачный OpenSearch как управляемый сервис. Это готовый индекс с морфологией, фасетами и горизонтальным масштабированием.
• Объектное хранилище — S3-совместимое (Yandex Object Storage, VK Cloud, AWS S3) + CDN для медиа.
• Очередь сообщений — RabbitMQ или управляемый Kafka уже на MVP для асинхронных уведомлений и обработки заказов.

Метрики, сигнализирующие, что пора выделять сервис:

• Команда, работающая над доменом, регулярно конфликтует с другими командами в одном репозитории.
• Конкретный модуль требует в 10× большей capacity, чем остальное приложение.
• Time-to-deploy для одного домена растёт из-за общего пайплайна сборки.

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

Частые вопросы (FAQ)

Чем архитектура маркетплейса отличается от интернет-магазина?

Ключевое отличие — мультивендорность: в маркетплейсе тысячи продавцов, у каждого свой каталог, остатки и ценообразование. Архитектура маркетплейса добавляет подсистему кабинета продавца, модерацию контента, многостороннюю финансовую логику (эквайринг + эскроу + разделение выручки), сложный OMS с маршрутизацией заказов между мерчантами и защиту от мошенничества на стороне продавцов.

Маркетплейс нужно сразу делать на микросервисах?

Нет. На старте достаточно модульного монолита — хорошо структурированного приложения с чёткими границами между доменами (каталог, заказы, платежи). Это ускоряет MVP и снижает операционную сложность. Выделять сервисы стоит только когда конкретный модуль становится узким местом по нагрузке, требует независимого деплоя или у него появляется отдельная команда разработки.

Как в маркетплейсе устроены выплаты продавцам?

Деньги покупателя поступают на счёт платформы и холдируются (эскроу) до подтверждения доставки. Затем платформа выполняет сплит-платёж: комиссия остаётся на платформе, остаток переводится продавцу. Все операции должны быть идемпотентными — каждая транзакция имеет уникальный идемпотентный ключ, чтобы при сетевом сбое или retry деньги не списались дважды.

Какая база данных подходит маркетплейсу?

Нет одной базы для всего. Финансовые операции и заказы — PostgreSQL (ACID, целостность). Каталог с полнотекстовым поиском — Elasticsearch или OpenSearch. Сессии, корзины, счётчики — Redis. Медиафайлы — объектное хранилище (S3-совместимое) + CDN. Попытка хранить всё в одной реляционной БД — типичная архитектурная ошибка, которая проявится под нагрузкой.

Как маркетплейс выдерживает распродажи и пиковый трафик?

Комбинация нескольких подходов: горизонтальное масштабирование (добавление инстансов) с балансировщиком, агрессивное кэширование каталога и статики, асинхронная обработка заказов через очереди (Kafka/RabbitMQ), идемпотентность операций с корзиной и оплатой, rate limiting на API, предварительный прогрев кэша за несколько часов до акции.

Сколько стоит и сколько длится разработка архитектуры маркетплейса?

Зависит от стадии: MVP с ограниченным набором категорий и ручной модерацией — несколько месяцев работы команды, полноценная мультивендорная платформа с автоматизированным эскроу и поиском — от полугода и дольше. Стоимость определяется командой, стеком и функциональными требованиями. Конкретный расчёт — на странице услуги разработки маркетплейса.