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

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

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

С чего начинается архитектура

Сначала опишите, кто участвует в процессе и какие действия совершает. Продавец, покупатель, сотрудник, склад, бухгалтерия. У каждого свои данные и права.

• Кто продаёт и кому принадлежит товар.
• Кто принимает заказ и кто его собирает.
• Кто платит и кто получает выплату.
• Кто отвечает за доставку и возврат.
• Кто модерирует товары и споры.

Ключевые домены

Заказы и позиции

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

• Заказ и позиции — разные сущности.
• Статус заказа и статус позиции.
• Оплата, сборка, отправка и доставка.
• Отмена и возврат по позиции.
• История изменений и ответственные.

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

Продавцы и выплаты

Выплаты — отдельный домен. Он не должен быть просто полем в заказе. Нужны начисления, удержания, история и статусы.

• Правила комиссии по категориям и продавцам.
• Начисления по заказам.
• Удержания за доставку и возвраты.
• Статусы выплат.
• Отчёты и документы.

Склады и резервы

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

• Резерв при оформлении.
• Списание после оплаты или сборки.
• Возврат на склад.
• Перемещение между складами.
• Массовый импорт и выгрузка.

Роли и доступ

В маркетплейсе много участников. Права должны быть минимальными и понятными: продавец видит только своё, сотрудник — свой участок, администратор — правила.

• Роли продавца и сотрудника.
• Ограничение по складам и заказам.
• Журнал действий.
• Двухфакторная аутентификация.
• Запрет на чужие выплаты и данные.

Очереди и интеграции

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

• Очереди для выгрузок и выплат.
• Повторные попытки и логи.
• Мониторинг задержек.
• Тестовый контур.
• План отката.

Этапы запуска

Типичные ошибки

• Один статус на весь заказ.
• Выплаты как поле в заказе.
• Нет резервов остатков.
• Продавец видит лишние данные.
• Запуск сразу с полной функциональностью.

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

Модерация

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

• Проверка продавца и документов.
• Правила публикации товаров.
• Стоп-слова и запрещённые категории.
• Очередь модерации и причины отказа.
• История решений и апелляции.

Споры и возвраты

Спор — это не сбой, а часть процесса. Важно понимать, кто отвечает за товар, доставку и возврат денег.

• Статусы спора и ответственные.
• Сроки ответа продавца.
• Возврат товара и денег.
• История переписки.
• Правила блокировки.

Отчёты

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

• Продажи по периодам.
• Комиссии и удержания.
• Статусы выплат.
• Остатки и резервы.
• Выгрузка отчётов.

Безопасность

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

• Минимальные права и журналы.
• Двухфакторная аутентификация.
• Мониторинг выплат и очередей.
• Резервные копии.

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

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

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

• Товары и остатки.
• Заказы и статусы.
• Начисления и выплаты.
• Документы и реквизиты.
• Поддержка и споры.

Интеграции

Маркетплейс почти всегда связан с 1С, складом, платежами и доставкой. Чем больше участников, тем важнее очередь и мониторинг.

• Обмен товарами и остатками.
• Заказы и статусы.
• Платежи и выплаты.
• Доставка и трек-номера.
• Логи и повторные попытки.

Масштабирование

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

• Индексы под заказы и выплаты.
• Очереди для тяжёлых операций.
• Кэш каталога.
• Мониторинг очередей.

Не пытайтесь сразу построить «второй Ozon». Сначала стабильные заказы, остатки и выплаты, затем всё остальное.

Комиссии и правила

Комиссия может зависеть от категории, продавца и акции. Правила должны быть видны до продажи.

• База расчёта.
• Учёт доставки и скидок.
• Разные ставки.
• История изменений.

Модерация и споры

Без модерации маркетплейс теряет доверие, но ручная проверка не масштабируется.

• Правила публикации.
• Очередь проверки.
• Причины отказа.
• История споров.

Начните с ручной модерации и автоматических стоп-слов. Полную автоматизацию добавите позже.

Что оставить на потом

Не все функции нужны на старте. Некоторые только усложняют запуск и поддержку.

• Сложная персонализация.
• Многоуровневые акции.
• Автоматические споры.
• Продвинутая аналитика.

Сначала стабильные заказы, остатки и выплаты. Всё остальное — после проверки модели.

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

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

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