Как это сделано: архитектура популярного российского маркетплейса на примере условного проекта

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

Мы разберём устройство условного крупного российского маркетплейса изнутри: из каких блоков он состоит, почему одни части обязательно выделяют в отдельные сервисы, как система переживает пиковые распродажи и какие инженерные просчёты чаще всего ломают пользовательский опыт.

Что вообще считается архитектурой маркетплейса

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

Основные требования к такой системе

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

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

Из чего состоит условный российский маркетплейс

Ниже — типовая схема, на которой строится современный крупный e-commerce-проект в России. Это не догма, но практически любой зрелый игрок проходит через похожий набор сервисов.

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

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

Монолит подходит, если проект небольшой

На старте маркетплейс иногда делают как единое приложение. Это проще и быстрее для запуска: одна кодовая база, один деплой, меньше согласований между командами. Когда ассортимент исчисляется тысячами позиций, а трафик не превышает нескольких сотен запросов в секунду, монолит вполне справляется. Но с ростом каталога, количества продавцов и нагрузки такой подход начинает мешать быстрее, чем кажется.

Минусы монолита в e-commerce

• любое, даже незначительное изменение кода затрагивает весь проект и требует полного регрессионного тестирования;
• сложно масштабировать отдельные участки — приходится разворачивать новые экземпляры всего приложения, даже если узким местом является только поиск;
• релиз одного модуля может неожиданно сломать другой из-за неявных зависимостей;
• команда быстро упирается в технический долг: кодовая база разбухает, а внедрение новых функций замедляется экспоненциально.

Микросервисы нужны для масштабирования

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

Плюсы микросервисной архитектуры

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

Но есть и минусы

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

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

Как выглядит путь пользователя внутри системы

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

1. Пользователь открывает главную страницу

Фронтенд получает данные о баннерах, подборках, акциях и персональных блоках. Часть контента — особенно статические баннеры и популярные категории — может быть отдана через CDN или закэширована на стороне API Gateway. Это позволяет главной открываться быстро даже при высокой нагрузке, не дёргая каждый раз бэкенд-сервисы.

2. Пользователь ищет товар

Запрос уходит в search service, где работает индексированный поиск. Обычно он не ищет «вживую» по всей базе данных, а использует заранее подготовленные индексы — например, на базе Elasticsearch или аналогичного движка. Это ускоряет выдачу в десятки раз по сравнению с прямыми SQL-запросами к каталогу.

3. Пользователь открывает карточку

Карточка товара собирается из нескольких источников:

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

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

4. Товар добавляется в корзину

Корзина должна быть быстрой и устойчивой к сбоям. Она не требует такой же строгости, как заказ, но обязана сохранять содержимое между устройствами и сессиями. Часто для хранения корзины используют высокопроизводительные key-value хранилища (например, Redis), а не реляционную базу, чтобы обеспечить минимальную задержку.

5. Оформляется заказ

На этом этапе подключаются самые критичные сервисы:

• проверка актуальных остатков и резервирование товара;
• расчёт стоимости доставки с учётом адреса и выбранного слота;
• создание платежа и его проведение;
• запись заказа в базу с уникальным идентификатором;
• отправка уведомления покупателю и продавцу.

Именно здесь чаще всего возникают ошибки, если система плохо спроектирована: дублирование заказов, потеря резерва, расхождение суммы платежа. Поэтому каждый шаг должен быть идемпотентным и транзакционно согласованным на уровне бизнес-логики.

6. Заказ идет в доставку

После успешной оплаты заказ передаётся в логистический контур. Там учитываются склад отгрузки, транспортная компания, адрес, временной слот и возможная передача в пункт выдачи. Delivery Service отслеживает статусы и обновляет их по мере движения товара, часто интегрируясь с внешними API курьерских служб.

Почему у маркетплейса отдельный поиск

Поиск — один из ключевых элементов коммерческого успеха. Пользователь часто не листает каталог вручную, а сразу ищет нужную модель, размер или бренд. Если поиск работает плохо, конверсия падает радикально.

Что должен уметь поиск

• понимать опечатки и предлагать исправления («айфон» вместо «iphone»);
• учитывать синонимы и словоформы («кроссовки» и «кеды» могут быть в одной группе);
• ранжировать товары по релевантности, а не только по точному совпадению;
• поддерживать динамические фильтры по цене, бренду, наличию;
• быстро работать по миллионам позиций — задержка более 200 мс уже заметна пользователю;
• учитывать наличие на складе и актуальную цену, чтобы не показывать недоступные товары.

Типовые технологии

В таких проектах часто используют поисковые движки на базе отдельных индексов. Это может быть Elasticsearch, OpenSearch или собственная поисковая надстройка над Apache Solr. Смысл один: вынести полнотекстовый поиск из основной базы данных, чтобы не нагружать её тяжёлыми запросами с сортировкой по релевантности. Индексы обновляются асинхронно по мере изменения каталога и остатков.

Частая ошибка

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

Каталог: как не запутаться в миллионах товаров

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

Что входит в каталог

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

Почему каталог лучше делать через отдельный сервис

У каталога своя сложная логика:

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

Выделение каталога в отдельный сервис позволяет независимо масштабировать его, кэшировать и оптимизировать под частые чтения.

Нюанс, о котором часто забывают

Каталог и склад — это не одно и то же. Товар может быть описан в каталоге со всеми фото и характеристиками, но физически отсутствовать на складе. Если эти слои путают, пользователю показывают товар, который нельзя купить, что вызывает разочарование и снижает доверие. Поэтому Inventory Service должен быть единственным источником правды об остатках, а каталог лишь предоставляет витринные данные.

Как маркетплейс справляется с нагрузкой

Пиковая нагрузка — это не теория. Для маркетплейса она возникает на распродажах, в праздничные дни, после рекламных кампаний и при выходе популярных товаров. Без грамотной подготовки система может лечь за секунды.

Основные приемы масштабирования

Кэширование

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

CDN

Статические файлы, изображения товаров и часть контента отдаются через CDN. Это ускоряет загрузку для пользователей из разных регионов России и снижает нагрузку на origin-серверы. Для маркетплейса с миллионами изображений это обязательный компонент.

Очереди

Если операция не требует мгновенного ответа, её уводят в очередь сообщений (Kafka, RabbitMQ, облачные аналоги):

• отправку уведомлений;
• обновление поисковых индексов;
• пересчёт рекомендаций;
• синхронизацию с внешними системами (ERP продавца, службы доставки).

Это позволяет разгрузить синхронные запросы и гарантировать доставку даже при пиковых нагрузках.

Горизонтальное масштабирование

Если один сервер не справляется, добавляют новые экземпляры сервиса за балансировщиком. Это базовый принцип устойчивого роста. Важно, чтобы сами сервисы не хранили состояние локально, иначе масштабирование превратится в проблему.

Разделение горячих и холодных данных

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

Базы данных: почему их обычно несколько

Одна база на все задачи — слабое решение для крупного маркетплейса. Разные данные требуют разной модели хранения и обработки.

Типовая комбинация

• реляционная база (PostgreSQL, MySQL) для заказов, платежей и пользователей — где нужна строгая согласованность и транзакции;
• поисковый индекс (Elasticsearch) для каталога и выдачи — оптимизирован под полнотекстовый поиск и фильтрацию;
• кэш (Redis) для часто запрашиваемых данных: корзины, сессий, горячих карточек;
• хранилище файлов (S3-совместимое) для изображений и документов — дешёвое и масштабируемое;
• аналитическое хранилище (ClickHouse, колоночная БД) для отчётности и BI — чтобы агрегации не тормозили боевые операции.

Почему нельзя хранить все в одной БД

Потому что:

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

Что происходит с заказом внутри системы

Заказ — это не одна запись, а цепочка состояний, каждое из которых должно быть зафиксировано и проверено.

Пример жизненного цикла

1. Создан черновик — пользователь нажал «Оформить», но ещё не оплатил.
2. Товар зарезервирован — система уменьшила доступный остаток, чтобы избежать перепродажи.
3. Оплата подтверждена — платёжный шлюз вернул успешный статус.
4. Заказ передан на сборку — склад получил задание.
5. Заказ отгружен — товар передан в доставку.
6. Доставлен — получен покупателем.
7. Закрыт — все обязательства выполнены, возможен возврат.

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

Важный технический принцип

Операции должны быть идемпотентными. Это значит, что повторный запрос (например, из-за сетевого сбоя или двойного клика) не должен создавать второй такой же заказ или списывать деньги дважды. Для интернет-торговли это критично: сеть нестабильна, а пользователь может нажать кнопку несколько раз. Обычно идемпотентность достигается через уникальные ключи операций и проверку статуса перед выполнением.

Личный кабинет продавца: отдельный мир внутри маркетплейса

У маркетплейса обычно два больших интерфейса: покупательский и продавецкий. Для продавцов нужен полноценный кабинет управления ассортиментом, который по сложности не уступает внутренней CRM.

Что в нем обычно есть

• загрузка карточек товаров — вручную или через API/фиды;
• управление ценами и скидками;
• остатки и склады — с возможностью резервирования под акции;
• документооборот: счета, акты, закрывающие документы;
• аналитика продаж и отчёты;
• обработка возвратов и претензий;
• ответы на отзывы и вопросы покупателей;
• управление рекламными кампаниями внутри площадки.

Почему это важно архитектурно

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

Безопасность и данные пользователей

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

Что обязательно должно быть в системе

• шифрование передаваемых данных (TLS) и хранение секретов в защищённых хранилищах;
• разграничение прав доступа на уровне сервисов и пользователей;
• журналирование всех критичных действий;
• защита от подмены запросов (CSRF) и инъекций;
• контроль сессий и своевременная инвалидация токенов;
• регулярные проверки безопасности и пентесты;
• резервное копирование с возможностью быстрого восстановления.

Типовая ошибка

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

Наблюдаемость: как понять, что все работает

Сложный маркетплейс нельзя «держать на ощущениях». Нужны метрики, логи и трассировка запросов, чтобы видеть реальную картину в реальном времени.

Что смотрят в первую очередь

• время ответа сервиса (latency) — по перцентилям, а не только среднее;
• процент ошибок (error rate) в разрезе эндпоинтов;
• задержки в очередях — если они растут, система не справляется с потоком;
• процент успешных оплат — падение на 1% уже повод для тревоги;
• скорость индексации каталога — новые товары должны появляться в поиске за минуты;
• конверсию из поиска в заказ — интегральный показатель здоровья;
• расхождение остатков между складом и витриной;
• количество отмен заказов по техническим причинам.

Зачем это нужно

Если у пользователей резко упала конверсия, причина может быть не в дизайне, а в том, что:

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

Без наблюдаемости такие проблемы ищут слишком долго, теряя выручку. Поэтому в зрелых командах мониторинг и алертинг встроены в культуру разработки.

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

1. Слишком ранняя сложность

Команда сразу строит десятки сервисов без реальной необходимости. В итоге растёт не устойчивость, а количество точек отказа, а сопровождение лавинообразно усложняется. Микросервисы должны появляться тогда, когда монолит перестаёт справляться, а не «на всякий случай».

2. Нет четких границ между сервисами

Если один сервис начинает делать всё подряд — и каталог, и заказы, и уведомления — архитектура снова превращается в монолит, только распределённый и ещё более сложный в сопровождении. Границы должны определяться бизнес-доменами.

3. Слабая работа с кэшем

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

4. Смешение каталога и остатков

Это приводит к товарным карточкам с неверной доступностью: товар виден, но не резервируется. Покупатель разочарован, продавец теряет доверие к площадке.

5. Отсутствие идемпотентности

Дубли заказов и платежей — прямой финансовый риск. Каждая операция, меняющая состояние (создание заказа, списание), должна быть защищена от повторного выполнения.

6. Слабая аналитика

Если команда не видит путь пользователя от входа до покупки, она оптимизирует интерфейс вслепую. Без данных о воронке, отказах и узких местах сложно принимать обоснованные продуктовые решения.

Как понять, что архитектура удачная

Хорошую архитектуру в e-commerce видно не по диаграмме, а по поведению системы в реальных условиях.

Признаки здорового решения

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

Чек-лист для оценки маркетплейса изнутри

• Есть ли отдельный поиск, а не запросы прямо в основную БД?
• Разделены ли каталог, заказы, оплата и доставка на независимые сервисы?
• Используется ли кэш для популярных страниц и карточек?
• Есть ли очереди для второстепенных операций, чтобы не блокировать основной поток?
• Защищены ли пользовательские данные на всех уровнях?
• Поддерживается ли идемпотентность критичных операций (заказ, платёж)?
• Есть ли мониторинг ключевых бизнес-метрик и алертинг?
• Можно ли обновлять отдельные модули без полной остановки системы?

Вывод

Архитектура маркетплейса — это баланс между скоростью, надёжностью и гибкостью. Чем больше проект, тем важнее разделять каталог, поиск, заказы, оплату, доставку и кабинет продавца на независимые блоки. Именно так система выдерживает нагрузку, не теряет данные и остаётся удобной для пользователя.

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

FAQ

Почему маркетплейсы не делают одним приложением?

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

Что важнее для маркетплейса: поиск или каталог?

Оба блока критичны, но поиск сильнее влияет на конверсию, потому что многие пользователи начинают путь именно с него. Если поиск не находит товар, клиент уходит, даже если каталог идеально структурирован. Однако без качественного каталога поисковому индексу нечего будет индексировать — они работают в связке.

Зачем маркетплейсу отдельный сервис доставки?

Чтобы независимо управлять сроками, слотами, трекингом и интеграциями с логистическими партнёрами. Логистика имеет свою сложную бизнес-логику: расчёт тарифов, маршрутизация, учёт географии складов. Выделение в отдельный сервис позволяет развивать её без оглядки на другие части системы и подключать новых перевозчиков без переписывания ядра.

Почему товары иногда есть в каталоге, но недоступны к заказу?

Потому что каталог описывает товар, а доступность определяет склад и сервис остатков. Товар может быть в каталоге, но его физически нет ни на одном складе, либо он зарезервирован под другие заказы. Если эти слои не разделены, витрина показывает неактуальную информацию, что приводит к негативному опыту.

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

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