Управление заказами на маркетплейсе — это не просто таблица в базе данных со столбцом «статус». Это центральный нерв всей платформы: от момента, когда покупатель нажал «Оплатить», до того, как курьер передал посылку и деньги дошли до продавца. Если эта система спроектирована плохо — сыпятся уведомления, зависают выплаты, растёт нагрузка на поддержку. В этой статье разберём архитектуру, статусную модель и ключевые интеграции, которые нужно заложить ещё на этапе проектирования.
Почему управление заказами — это отдельный архитектурный домен
На первый взгляд кажется, что заказ — это просто запись: товар, покупатель, сумма, адрес. На практике заказ на маркетплейсе затрагивает минимум 6–8 доменов: каталог, инвентарь, платёжный шлюз, логистику, уведомления, финансовый учёт, CRM продавца и аналитику. Каждый из них живёт по своим правилам и может упасть независимо от остальных.
Поэтому профессиональный подход — выделить Order Management System (OMS) в отдельный сервис или хотя бы чётко изолированный модуль. Он владеет «источником истины» о состоянии заказа и оркестрирует взаимодействие с остальными компонентами через события или API.
Жизненный цикл заказа: от корзины до закрытия
Прежде чем проектировать статусы, нужно зафиксировать все сценарии, через которые проходит заказ. Типичный жизненный цикл на маркетплейсе выглядит так:
- Корзина сформирована — позиции зарезервированы в инвентаре, но заказ ещё не создан.
- Заказ создан — запись появилась в OMS, ожидается оплата.
- Оплата подтверждена — платёжный шлюз вернул успешный callback.
- Передан продавцу — продавец получил уведомление и должен подтвердить наличие.
- Принят продавцом — продавец подтвердил, начинается сборка.
- Передан в доставку — создан трек-номер, логистический оператор принял груз.
- Доставлен — покупатель получил товар, статус подтверждён (вручную или автоматически).
- Завершён — период возврата истёк, деньги переведены продавцу.
Параллельно существуют ветки: отмена на любом этапе, частичный возврат, спор (dispute), повторная доставка. Все эти переходы нужно описать до начала разработки — иначе потом придётся переписывать схему БД и ломать уже работающие интеграции.
Статусная модель: как не запутаться в переходах
Главное правило — статус должен описывать состояние системы, а не действие пользователя. «Оплачен» — хороший статус. «Нажата кнопка оплаты» — плохой.
Рекомендуем разделять статусы на два уровня:
- Системный статус — технический, для внутренней логики и интеграций (например,
payment_captured,fulfillment_pending). - Пользовательский статус — то, что видит покупатель в личном кабинете («Оплачен», «Собирается», «В пути»).
Это разделение позволяет менять внутреннюю логику без изменения интерфейса и наоборот — переформулировать текст для покупателя, не трогая бизнес-логику.
| Системный статус | Пользовательский статус | Кто инициирует переход |
|---|---|---|
| created | Ожидает оплаты | Система (создание заказа) |
| payment_captured | Оплачен | Платёжный шлюз (webhook) |
| seller_accepted | Принят продавцом | Продавец (личный кабинет) |
| in_delivery | В пути | Логистический оператор (API) |
| delivered | Доставлен | Оператор или покупатель |
| completed | Завершён | Система (таймер) |
| cancelled | Отменён | Покупатель / продавец / система |
Мультипродавец: главная сложность архитектуры
На маркетплейсе покупатель может положить в одну корзину товары от трёх разных продавцов. Это означает, что один «пользовательский заказ» должен быть разбит на несколько субзаказов (или fulfillment orders) — по одному на каждого продавца.
Каждый субзаказ живёт по своему жизненному циклу, имеет собственный статус и независимую логистику. Родительский заказ при этом агрегирует их состояния: он считается «Доставленным» только тогда, когда все субзаказы доставлены.
Это влияет на финансовую модель: платёж один, но расщепление (split payment) происходит на уровне субзаказов. Если один продавец отменил позицию — нужно вернуть часть суммы покупателю, не затрагивая остальных продавцов. Такая логика требует поддержки со стороны платёжного шлюза (например, Stripe Connect, ЮKassa с разделением) и должна быть заложена в архитектуру с нуля — добавить её постфактум крайне сложно.
Ключевые интеграции OMS
Система управления заказами не работает в изоляции. Вот минимальный набор интеграций, без которых OMS не будет полноценной:
- Платёжный шлюз — приём webhook о смене статуса платежа, инициация возвратов.
- Инвентарь — резервирование и списание остатков при создании и отмене заказа.
- Логистика — создание отправлений, получение трек-номеров, отслеживание статусов доставки.
- Уведомления — email, push, SMS при каждом значимом переходе статуса.
- Финансовый модуль — расчёт комиссии маркетплейса, формирование выплат продавцам.
- Аналитика — передача событий заказа для построения воронок и когортного анализа.
Каждую интеграцию нужно проектировать с учётом идемпотентности: webhook от платёжного шлюза может прийти дважды, и система не должна дважды списать товар или дважды отправить деньги продавцу.
Типичные ошибки при проектировании
За годы работы над проектами по разработке маркетплейса мы видели одни и те же грабли. Вот самые дорогостоящие из них:
- Статусы как строки без валидации переходов. Если любой сервис может записать любой статус — это хаос. Переходы должны быть разрешены явно, а попытка недопустимого перехода — возвращать ошибку.
- Отсутствие истории изменений. Без лога переходов невозможно разобрать спор с покупателем и отладить баг. Храните каждое изменение статуса с timestamp и источником.
- Синхронные вызовы в критическом пути. Если при создании заказа вы синхронно дёргаете API логистики — один сбой логистического оператора роняет весь checkout. Используйте очереди (Kafka, RabbitMQ, SQS).
- Единая таблица для всех типов заказов. Цифровые товары, физические, подписки — у каждого свой жизненный цикл. Не пытайтесь уместить их в одну схему.
- Игнорирование таймаутов. Что происходит, если покупатель создал заказ и не оплатил его 30 минут? Нужен планировщик, который автоматически отменяет такие заказы и снимает резерв с инвентаря.
Часто задаваемые вопросы
Сколько статусов заказа достаточно для маркетплейса?
Универсального числа нет — всё зависит от бизнес-модели. Для простого маркетплейса с одним типом товаров и одним логистическим оператором хватает 7–9 системных статусов. Для платформы с мультипродавцом, цифровыми товарами и подписками счёт идёт на 15–20. Важнее не количество, а чёткое описание допустимых переходов между ними и разделение на системные и пользовательские статусы.
Как организовать управление заказами маркетплейс при мультипродавце?
Стандартный подход — двухуровневая модель: родительский заказ (то, что видит покупатель) и субзаказы (fulfillment orders) по одному на каждого продавца. Родительский заказ агрегирует статусы субзаказов. Платёж проводится один раз на уровне родительского заказа, а расщепление средств происходит при переходе субзаказа в статус «Завершён». Это требует поддержки split payment на стороне платёжного шлюза.
Нужна ли отдельная микросервисная архитектура для OMS с самого начала?
Не обязательно. На старте вполне работает хорошо изолированный модуль в монолите с чёткими границами домена. Главное — не смешивать логику заказов с логикой каталога или авторизации. Переход к микросервису оправдан, когда нагрузка на OMS начинает влиять на производительность остальных частей системы, или когда разные команды начинают работать над разными доменами параллельно.
Итог и следующий шаг
Грамотно спроектированная система управления заказами — это инвестиция, которая окупается с первого же кризисного сценария: сбоя оплаты, спора с покупателем или резкого роста трафика. Закладывать её архитектуру нужно до написания первой строки кода, а не рефакторить на живом продукте.
Если вы планируете запуск платформы или хотите аудит существующей системы — команда Aris.Web готова помочь. Мы занимаемся разработкой маркетплейса под ключ: от проектирования архитектуры до запуска и масштабирования. Обсудите проект по телефону +7 (977) 326-69-09 или оставьте заявку на странице arisweb.ru/kontakty — ответим в течение рабочего дня.