Разработка маркетплейса: мультивендорная торговля, комиссии, модерация
Маркетплейс — это не интернет-магазин с несколькими продавцами. Это платформа, где бизнес-логика строится вокруг трёх сторон: покупатель, продавец, платформа. Каждая транзакция затрагивает всех троих. Ошибка в расчёте комиссии на 1000 заказов в день — это финансовые расхождения, которые невозможно разгрести без отдельного reconciliation процесса.
Мультиарендность: как разделяются данные
Две основные модели изоляции данных продавцов:
Shared database, shared schema — все продавцы в одних таблицах, каждая запись имеет vendor_id. Дешевле в инфраструктуре, проще в разработке. Риск: ошибка в WHERE-условии — продавец видит чужие заказы. Обязательно Row Level Security (RLS) на уровне PostgreSQL или глобальные scopes в ORM на всех запросах.
Shared database, separate schema (PostgreSQL schemas) — у каждого продавца своя схема в одной базе. Изоляция строже, но сложнее cross-vendor операции (статистика платформы, поиск по всем товарам).
Для большинства маркетплейсов до 10 000 продавцов — shared schema с RLS. Separate schema — для enterprise B2B с требованиями GDPR по изоляции данных.
Финансовая механика: комиссии и выплаты
Расчёт комиссии — самая критичная часть, где ошибки стоят денег.
Правило первое: никогда не хранить комиссию как производную, всегда как факт. В момент создания заказа фиксируем: сумму заказа, процент комиссии платформы в этот момент, абсолютное значение комиссии, сумму к выплате продавцу. Если завтра вы измените ставку комиссии — исторические заказы должны оставаться с прежними цифрами.
Модели комиссий:
- Фиксированный процент (5% с каждой продажи)
- Дифференцированный по категориям (электроника 3%, одежда 8%)
- Tiered по обороту (до 100k — 10%, от 100k — 7%)
- Смешанный: % + фиксированная сумма за транзакцию
Stripe Connect — стандарт для маркетплейсов. Два режима: Destination charges (платформа принимает платёж, переводит продавцу) и Direct charges (платёж идёт напрямую к продавцу, платформа забирает комиссию через application fee). Destination charges даёт платформе больше контроля, включая удержания при спорах.
Onboarding продавца в Stripe Connect: KYC/AML проверка через Stripe Identity или встроенный Stripe onboarding. Пока продавец не прошёл верификацию — выплаты заморожены. Продуманный UX этого процесса критичен для конверсии продавцов.
Escrow и холдирование. Деньги с покупателя списываются сразу, продавцу переводятся с задержкой (7–14 дней) после подтверждения получения. Это защита от мошенничества и возможность удержания при спорах. Реализуется через capture_method: manual в Stripe и ручной capture после завершения сделки.
Каталог с мультивендорными товарами
Одна из сложных задач: один и тот же товар может продаваться несколькими продавцами. Два подхода:
Unified catalog (как Amazon): есть единая карточка товара (product), к которой привязаны предложения разных продавцов (offers) с разными ценами и остатками. Поиск и SEO по карточке, не по офферу. Сложность: кто создаёт карточку, кто за неё отвечает, как резолвить конфликты атрибутов от разных продавцов.
Per-vendor catalog (как Avito): каждый продавец ведёт собственные карточки независимо. Дубликаты — норма. Проще в разработке и в отношениях с продавцами, сложнее для покупателя (сравнение предложений).
Для нишевого B2B маркетплейса — per-vendor проще и быстрее запускается. Для горизонтального retail с большим количеством продавцов — unified catalog даёт лучший UX.
Складские остатки в реальном времени. Два покупателя одновременно добавляют последний товар в корзину. Кто его купит? Optimistic locking при создании заказа: UPDATE inventory SET reserved = reserved + 1 WHERE product_id = ? AND (quantity - reserved) >= 1 — атомарная операция, второй запрос вернёт 0 затронутых строк и получит ошибку «товар закончился».
Модерация контента
Маркетплейс несёт ответственность за контент продавцов. Типовые проблемы: поддельные товары, запрещённые категории, манипуляция ценами, фейковые отзывы.
Moderation pipeline:
- Автоматические проверки при публикации: обязательные поля, соответствие категории, ограничения по словам (стоп-лист), дубликаты через хеш изображения
- AI-классификация: определение категории по тексту и изображению, детекция запрещённого контента (Rekognition или Vertex AI Vision)
- Очередь ручной проверки для flagged товаров
Статусная машина для товара: draft → pending_review → active / rejected → suspended. Каждый переход — событие с причиной и модератором. Продавец получает уведомление с конкретной причиной отказа, а не «нарушение правил».
Отзывы: верификация покупки обязательна (отзыв только от пользователя с подтверждённым заказом на этот товар). Автоматический детектор подозрительной активности: резкий рост отзывов от аккаунтов с нулевой историей — флаг для ручной проверки.
Dispute resolution: продавец и покупатель не могут самостоятельно урегулировать — арбитраж платформы. Временные ограничения на каждый этап (покупатель открывает спор в течение N дней, продавец отвечает в течение M дней). Интеграция с Stripe Disputes для автоматического ответа на chargeback.
Поиск и рекомендации
Поиск по маркетплейсу с разными продавцами и сотнями тысяч товаров — это Elasticsearch или OpenSearch, не SQL LIKE. Векторный поиск для семантики (см. AI категорию), фасетная фильтрация через агрегации Elasticsearch.
Персонализированная лента: клики, покупки, просмотры → коллаборативная фильтрация или content-based рекомендации. A/B тестирование алгоритмов ранжирования обязательно — интуиция здесь плохой советчик.
Процесс работы
Маркетплейс — итеративная разработка. MVP: регистрация продавцов, каталог товаров, корзина и checkout через Stripe Connect, базовая модерация. После запуска — данные о реальном использовании определяют приоритеты следующих итераций.
Типичный порядок: MVP (3–4 месяца) → аналитика и обратная связь → первый расширенный релиз (2–3 месяца) → масштабирование и оптимизация.
Сроки
MVP маркетплейса (каталог, checkout, базовые профили продавцов): 3–5 месяцев. Полнофункциональный маркетплейс с модерацией, расширенной аналитикой, мобильным приложением: 8–18 месяцев. Добавление маркетплейс-функциональности к существующему e-commerce: 2–5 месяцев.