Разработка маркетплейса
Маркетплейс — площадка, где встречаются продавцы и покупатели, а платформа берёт комиссию или плату за размещение. Архитектурно это сложнее интернет-магазина: нужно управлять несколькими сторонами, балансировать расщепление платежей между продавцами и платформой, обеспечивать доверие через отзывы и систему гарантий.
Ключевые сущности и роли
Покупатель (buyer): поиск товаров, добавление в корзину, оформление заказа, отзывы, споры.
Продавец (seller/merchant): регистрация магазина, управление каталогом, обработка заказов, получение выплат.
Оператор (admin): модерация товаров и продавцов, управление комиссиями, разрешение споров, финансовая аналитика.
Архитектура платёжного слоя
Ключевое отличие маркетплейса от обычного магазина — расщепление платежей (split payment). Покупатель платит одну сумму, которая автоматически делится: часть идёт продавцу, часть остаётся платформе.
Stripe Connect — стандарт для западных рынков:
Buyer → Stripe → Platform account
↓
Transfer to seller (connected account)
Platform keeps fee automatically
Схемы Stripe Connect:
- Direct — продавец полностью подключён к Stripe, видит клиентские данные
- Destination — деньги идут через платформу и переводятся продавцу
- Separate charges + transfers — максимальная гибкость, нужна для multi-vendor cart
На рынках СНГ: ЮКасса (Сплитование через API deals + payouts), CloudPayments через агентскую схему.
Пример создания Transfer в Stripe:
import stripe
stripe.Transfer.create(
amount=8500, # в центах
currency="usd",
destination="acct_1BuAYuBnMOckkSJp", # seller's connected account
transfer_group="ORDER_95",
)
Поиск и каталог
Для маркетплейса с тысячами товаров от разных продавцов полнотекстового поиска базы данных недостаточно. Типовой стек:
- Elasticsearch или OpenSearch — индексация товаров с фасетной фильтрацией (категория, цена, продавец, рейтинг, атрибуты)
- Meilisearch — более лёгкая альтернатива для малого/среднего маркетплейса (до ~1 млн документов)
Фасетный поиск требует хранения индексируемых атрибутов как отдельных полей, а не JSON-блоба.
Система отзывов и рейтингов
Отзыв должен быть верифицирован: только покупатель, фактически получивший товар, может оставить отзыв. Триггер — смена статуса заказа на delivered или completed + N дней. Продавец может ответить на отзыв.
Рейтинг продавца вычисляется по скользящему среднему, часто с весовым коэффициентом по давности (свежие отзывы важнее старых).
Система разрешения споров
Спор (dispute) — сущность, возникающая при конфликте покупатель/продавец:
- Покупатель открывает спор
- Продавец отвечает
- Оператор выносит решение (возврат / в пользу продавца)
- Платёжная система исполняет решение (refund или transfer)
Таймауты: стандарт — продавец отвечает в течение 3 дней, оператор решает в течение 5 рабочих дней.
Технический стек
| Компонент | Варианты |
|---|---|
| Backend API | Laravel, Django, Node.js/Nest.js |
| Frontend | Next.js, Nuxt.js |
| База данных | PostgreSQL |
| Поиск | Elasticsearch, Meilisearch |
| Очереди | Redis + Bull/BullMQ, RabbitMQ |
| Платежи | Stripe Connect, ЮКасса |
| Хранение файлов | S3-совместимое (Cloudflare R2, MinIO) |
| Кэш | Redis |
Сроки разработки
MVP-маркетплейс (регистрация продавцов, каталог товаров, корзина, оплата с расщеплением, личные кабинеты продавца и покупателя, базовый поиск, панель администратора): 3–5 месяцев в зависимости от команды и объёма функций. Полноценная платформа с отзывами, спорами, аналитикой, мобильными приложениями — 6–12 месяцев.