Резерв, сделка и спор: state machine маркетплейса

Как связать объявление, резерв, оплату, отмену и спор в предсказуемую модель.

Зачем разбирать эту тему

Каталог — простая часть маркетплейса. Сложность начинается, когда два пользователя хотят один товар, резерв истёк во время оплаты или после сделки появился спор.

Как устроена задача на практике

State machine делает разрешённые переходы явными: active → reserved → sold, а у сделки отдельно существуют paid, fulfilled, completed и disputed.

Что важно в production

Резерв создаётся атомарно, срок хранится на сервере, а возврат на success page не считается оплатой — статус меняется только после проверенного webhook.

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

Главная ошибка — выбирать технологию или паттерн раньше, чем сформулирован пользовательский сценарий и ограничения. Второй частый промах — проверять решение только на идеальном happy path и не продумывать восстановление после сбоя, повторный запрос и права доступа.

Практический вывод

Audit log хранит всю историю переходов. Интерфейс показывает только действия, которые разрешены текущим состоянием и ролью пользователя.

  • фиксируйте допущения до реализации;
  • проверяйте решение на реальных данных и устройствах;
  • сохраняйте наблюдаемость и возможность безопасного отката;
  • усложняйте архитектуру только когда это подтверждает задача.
PSP / EDITORIAL

Есть задача, где это решение нужно применить на практике?

← Все материалыОбсудить проект ↗