Кейс: маркетплейс
Сквозной кейс сайта в формате «я повторю, как понял задачу»: бизнес-описание маркетплейса своими словами, без архитектурных терминов. Этот текст затем прогоняется через скиллы методологии — из него получаются API, доменная модель и UseCase-ы.
Это сквозной пример сайта. Я взял типичный разговор «давайте я повторю, как понял задачу» — то, что обычно происходит после первой встречи с заказчиком, перед тем как браться за оценку и архитектуру.
Здесь нет ни строчки про базы данных, очереди и агрегаты. Здесь только бизнес — словами, какими о нём говорят сами участники. Этот текст потом отдаётся скиллам методологии, которые из него выводят технические артефакты: контракты API, доменную модель, UseCase-ы.
О чём вообще речь
Вы делаете маркетплейс — площадку, на которой одни люди продают свои товары другим людям. Сами вы при этом ничего не производите и не складируете: ваша роль — посредник с гарантиями.
Продавцы у вас разные: и крупные магазины с тысячами позиций, и частники, которые продают пару вещей в месяц. Покупатели — обычные люди. Между ними стоит ваша команда: модераторы карточек, операторы споров, бухгалтерия, поддержка.
Деньги вы зарабатываете двумя способами. Главный — комиссия с каждой подтверждённой продажи. Вспомогательные — платное продвижение в выдаче, сервисные сборы за упаковку и страховку.
Кто пользуется платформой
У платформы три основных «лица», и для каждого нужен свой интерфейс.
Покупатель заходит, чтобы найти и купить. Ему важны: цена, наличие, отзывы, скорость доставки. Логинится он чаще всего через телефон или соцсеть — пароли никто запоминать не хочет.
Продавец заходит, чтобы зарабатывать. Ему важны: быстро добавить товар, увидеть свои заказы, получить деньги в срок, быстро решить спор, если он возник. Логинится по корпоративному аккаунту — обычно с двухфакторной защитой.
Оператор маркетплейса — это ваши сотрудники: модераторы, специалисты по спорам, финансовый отдел. Они работают изнутри, через корпоративный SSO с обязательной MFA. У них самые широкие права, поэтому каждое действие пишется в аудит.
Есть ещё курьер и пункты выдачи — но они с платформой общаются через свои API, а не через интерфейсы. Их мы рассматриваем как внешние сервисы.
Что есть на платформе
Чтобы дальше говорить на одном языке, давайте зафиксирую, как мы называем вещи.
Товар — конкретное изделие у конкретного продавца. Один и тот же iPhone у двух разных продавцов — это два разных товара, потому что у них разная цена, остаток, рейтинг, продавец отвечает за свой. Это важно: товары не «склеиваются».
Карточка товара — то, что покупатель видит на витрине: фото, описание, цена, остаток, отзывы.
Корзина — временный набор товаров. Пока она не превратилась в заказ, ничего не зарезервировано: остаток может уйти к другому покупателю.
Заказ — финансовый документ. После оформления заказа товары резервируются, и продавец видит «ко мне приехала продажа».
Платёж — попытка списания денег. Один заказ может оплачиваться несколькими попытками: ввели не ту карту, не прошёл 3DS, попробовали ещё раз. Заказ становится оплаченным только после того, как банк подтвердил списание.
Возврат — обратное движение денег, когда товар возвращается. Не путать с отменой: отмена возможна до отправки, возврат — после получения.
Спор — это когда покупатель говорит «не то/брак/не пришло», а продавец не согласен. Тогда в дело вступает оператор и принимает решение.
Комиссия — ваш процент с подтверждённой продажи. Расчёт продавцу — это сумма, которую вы переводите ему раз в неделю: продажи минус комиссия минус возвраты.
Промокод — купон, дающий скидку на корзину или конкретные товары.
Как происходит покупка
Расскажу как историю, по шагам — так понятнее.
Покупатель открывает сайт или приложение. Ищет товар — через поиск или каталог. Открывает карточку, видит наличие, цену, продавца, отзывы. Если устраивает — кладёт в корзину.
В корзине покупатель может ввести промокод и выбрать способ доставки (адрес или ПВЗ). Итоговая сумма пересчитывается: товары × количество, минус скидки, плюс доставка.
Дальше нажимает «Оформить». Система резервирует остаток у каждого продавца, который попал в корзину, и переводит покупателя на форму оплаты. На эту операцию мы даём, например, 15 минут — если за это время оплата не пришла, резерв снимается, заказ помечается «истекший».
Когда платёж прошёл — заказ переходит в статус «оплачен». Продавец получает уведомление, собирает посылку и передаёт курьеру. Заказ становится «отправлен».
Курьер доставляет — заказ становится «доставлен». Если за следующие 14 дней покупатель не открыл спор — заказ закрывается, продавцу начисляется выручка.
Что бывает, когда что-то идёт не так
Это самая важная часть. На счастливый сценарий код пишут все, разница начинается в обработке проблем.
Покупатель передумал до отправки. Например, заказ оплачен, но продавец ещё не передал курьеру. Покупатель нажимает «Отменить». Резерв снимается, деньги возвращаются через тот же платёжный шлюз. Здесь всё просто.
Покупатель передумал, но посылка уже едет. Сложнее — нужно либо ждать, пока курьер вернёт пакет, либо договариваться, чтобы покупатель сам вернул в ПВЗ. Деньги возвращаются только после того, как товар физически вернулся продавцу.
Покупатель получил, но что-то не так. Брак, не тот цвет, кто-то распечатал коробку. Покупатель открывает спор, прикладывает фото и описание. Платформа уведомляет продавца — у него три дня на ответ. Если согласен — оформляется возврат. Если нет или молчит — спор уходит к оператору, тот разбирается и принимает решение. Решение фиксируется в системе как часть истории заказа — на случай, если кто-то потом захочет проверить.
Платёжный шлюз отвалился. Покупатель ввёл карту, банк не отвечает 30 секунд. Мы не можем оставить его в подвешенном состоянии — у нас должна быть стратегия: показать «попробуйте снова», заморозить заказ на короткое время, проверить через минуту через альтернативный канал шлюза. К этому ещё вернёмся, когда дойдём до отказоустойчивости.
Деньги уже выплачены продавцу, а покупатель открыл возврат. Самый болезненный случай. Платформа не может «отозвать» уже отправленную выплату — деньги списываются с внутреннего баланса продавца, и в следующих расчётах он получит меньше. Если баланс ушёл в минус — заказы продавца замораживаются до выяснения.
Что делает продавец
У продавца своя жизнь на платформе.
Размещает товары. Создаёт карточку, заполняет описание, ставит цену и остаток, выбирает категорию. Карточка идёт на модерацию — оператор проверяет, что нет запрещённых вещей и категория правильная. Если ОК — карточка появляется в каталоге; если нет — возвращается с комментарием.
Обрабатывает заказы. Видит у себя в кабинете «вот четыре новых заказа». Собирает, передаёт курьеру, отмечает в системе.
Получает выплаты. Раз в неделю система собирает все его закрытые заказы, считает: продажи минус ваша комиссия минус возвраты минус штрафы, если были. Если итог больше порога выплаты (например, 1000 ₽) — деньги уходят на расчётный счёт продавца. Если меньше — остаток копится до следующей недели.
Видит отчёты. Сколько продал, какая средняя комиссия, какие товары вернули чаще всего. Это и для самого продавца полезно, и снимает нагрузку с поддержки — меньше вопросов «а где мои деньги».
Что делает оператор маркетплейса
Операторы — это ваша команда внутри. Они закрывают всё, что не получается автоматизировать.
Модераторы смотрят новые карточки товаров. Специалисты по спорам разбирают конфликты между покупателями и продавцами. Финансовый отдел проверяет крупные выплаты и решает, что делать с заблокированными аккаунтами. Поддержка отвечает покупателям и продавцам по обычным вопросам.
У оператора широкие права, поэтому каждое его действие пишется в аудит — кто, когда, на каком заказе, что изменил. Это нужно и для безопасности, и на случай разбирательств.
Что важно держать в голове
Несколько правил, которые звучат очевидно, но определяют половину работы.
- Сумма заказа = всегда сумма позиций минус скидки плюс доставка. Никаких «расхождений на копейку», иначе бухгалтерия сломается.
- Резервировать можно только то, что есть в наличии. Отрицательных остатков не бывает — резерв либо успешен, либо отказан.
- Один промокод — одно применение в одном заказе. Не складываются.
- Продавец не может изменить цену уже оформленного заказа. Защита покупателя.
- После отправки заказ нельзя «отменить» одной кнопкой — только оформить возврат с обратным движением товара.
- Возврат денег невозможен, если они уже выплачены продавцу — компенсируется с его внутреннего баланса.
- Спор может открыть только покупатель и только в течение 14 дней после получения. Защита от злоупотреблений.
- Покупатель видит только свои заказы. Продавец — только заказы со своими товарами. Оператор — все. Никто не видит чужого.
- Платёж считается успешным только при подтверждении от банка, не до. Никаких «оптимистичных» подтверждений.
Какие у нас цели по объёмам
Чтобы понимать, что мы строим — небольшой стартап или платформу национального масштаба, — давайте зафиксирую целевые цифры. Это не то, что у вас сейчас, а то, к чему вы готовитесь.
| Что | Сколько |
|---|---|
| Активных продавцов | 200 000 — 500 000 |
| Карточек товаров на витрине | 50 — 100 миллионов |
| Активных покупателей в месяц | 10 — 15 миллионов |
| Заказов в обычный день | около 500 000 |
| Заказов в пиковый день (Чёрная пятница, 11.11) | до 2 миллионов |
| Запросов к поиску и каталогу | до 50 000 в секунду |
| Запросов на оформление заказа | 200 — 500 в секунду |
| Подключённых платёжных шлюзов | 5 — 10 |
При таких числах «один сервер с одной базой» физически не работает — придётся разносить нагрузку, делать кэши, использовать очереди. Это уже инженерная часть, на которую переходим в следующих главах.
Что вы хотите по надёжности и срокам
В разговорах с заказчиком обычно опускают эту часть, а зря — без неё инженеры не могут оценить стоимость.
Каталог и поиск должны работать «всегда» — потому что если упадут, не будет ни одной продажи. Целимся в 99.95% доступности, что значит — не больше 4 часов простоя в год.
Оформление заказа немного попроще — 99.9% (около 9 часов в год). Если коротко полежит ночью — это переживаемо.
Личный кабинет продавца — самый «терпимый» — 99.5%. Если он упал на полчаса в обед — продажи продолжаются, продавец зайдёт позже.
Персональные данные покупателей (адрес, телефон, ФИО) — храним зашифрованно, все обращения пишем в аудит, удаляем по запросу или через 5 лет после последнего заказа. Это требования российского 152-ФЗ.
Карты и счета — не храним вообще. Только токены от платёжного шлюза, который сам сертифицирован по PCI DSS. Это снимает с нас огромный пласт работы и риски.
Что мы не делаем в первой версии
Чтобы запуск был реалистичным, специально ограничиваем объём.
- Только Россия и только рубли. Без международной доставки, таможни, мультивалютности.
- Только обычные продавцы и покупатели. Без подмаркетплейсов, B2B-витрин с прайс-листами, реферальных программ.
- Только хранение у продавца. Без своих складов платформы, без FBO/FBM моделей.
- Без собственной курьерской службы. Только интеграции со внешними логистами.
Это бизнес-упрощения, не технические. Если позже захотите добавить — суть процессов и ролей не меняется, только усложняются детали. Архитектура должна позволять это сделать без переписывания.
Что дальше
Этот текст — то, как я понял ваш бизнес. Если что-то описано неверно — скажите сейчас, потому что на этом тексте дальше строится всё: API, интерфейсы, сроки, бюджет.
Когда мы согласуем понимание, дальше начинается уже инженерная часть:
- Контракты API — что именно может вызывать покупатель, продавец и оператор. Здесь помогут скиллы проектирования API.
- Что внутри — какие у нас будут сервисы, какие у них зоны ответственности, как они общаются. На этом этапе из бизнес-описания выводятся агрегаты, события, сценарии, а из них — конкретные UseCase + Handler-ы.
- Где может упасть — обработка ошибок шлюзов, ретраи, идемпотентность; см. паттерны отказоустойчивости и распределённые паттерны.
Артефакты по каждому сервису публикуются отдельными статьями кейса. Как они связаны с этим бизнес-описанием — описано в Use Case спецификации.