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

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

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

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

Мультивендорная архитектура

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

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

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

Оплата, расщепление и эскроу

Самый чувствительный блок — деньги. Когда покупатель платит, средства не должны мгновенно уходить продавцу. На рынке Узбекистана оплата обычно идёт через Click, Payme и Uzum, плюс наложенный платёж при доставке, который для маркетплейса создаёт отдельный пласт сверки наличных. Деньги покупателя нужно удержать до подтверждения, что заказ доставлен и не отменён, а затем расщепить: комиссия площадки — себе, остаток — продавцу.

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

Логистика и фулфилмент

В магазине доставка — приятное дополнение. В маркетплейсе это часть продукта. Нужно решить базовую модель: продавцы отгружают сами (marketplace-модель, FBS), или площадка принимает товар на свой склад и отгружает за продавца (фулфилмент, FBO). Большинство площадок в итоге поддерживают обе.

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

Монетизация

Маркетплейс зарабатывает не на марже от товара, а на инфраструктуре вокруг сделки. Основные модели обычно комбинируют:

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

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

Нагрузка и устойчивость

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

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