Почему остатки на маркетплейсах разъезжаются, и почему Kafka вам, скорее всего не нужна?

[raxer]

У нас платформа, которую мы даем селлерам, чтобы они в рамках одного обмена могли передавать и получать информацию (заказы, остатки, цены и т.д.) на все маркетплейсы.
И есть одна ювелирка, у которой более 100 000 SKU, где 90% остатков - 1 штука. И торгуют на 6 кабинетах всем этим добром.
Мы у себя реализовали следующим образом:
все заказы мы получаем через вебхуки.
в момент получения заказа мы минусуем остаток (который хранится у нас) и шлем изменения сразу во все кабинеты. Когда прилетает обновление остатков из учетной системы (1С), мы сравниваем когда менялся остаток в 1с и когда менялся у нас. Если наше обновление - более свежее - сохраняем его. Потом когда клиент на своей стороне все переварит и пришлет актуальный остаток, уже обновляем у себя.
таким образом мы не залетаем на ограничения API, и при этом время между поступлением заказа и списанием со склада на маркетплейсе составляет не более минуты.

[alleku]

Красивая схема, особенно локальный кэш как единый источник для всех кабинетов и разрешение конфликтов по времени, чтобы устаревший снапшот из 1С не откатывал свежее списание. На вашем профиле (90% позиций по одной штуке, 6 кабинетов) интересны два узких места, поделитесь как закрыли.

Первое, гонка на единственной единице. Между списанием на первом кабинете и обновлением на остальных пяти есть окно, вы пишете до минуты. За это окно ту же единицу может выкупить другой кабинет. Декремент атомарный, с проверкой что остаток больше нуля, и есть отдельная ветка на случай «продали то, чего уже нет» (авто-отмена или возврат)? На единичных остатках это срабатывает заметно чаще, чем кажется.

Второе, идемпотентность. Вебхуки прилетают at-least-once, дубль уведомления о заказе даёт двойное списание. Дедуп по номеру заказа перед списанием стоит?

И вдогонку: как живёте с дрейфом при разрешении конфликтов по таймстемпам 1С и вашему? Делаете периодическую полную сверку остатков или расхождение ловится уже на инвентаризации?

[raxer]

В нашей бизнес логике не страшно уйти в минус, так что мы не проверяем на нулевой остаток. В нашей базе хранится справочная информация поэтому нам важно именно фиксануть когда товар кончился. Получится 0 или -1 - не важно. На маркетплейсы передастся остаток 0.

Финально работает так: пуш от маркетплейса создает заказ в системе, который списывает одну единицу с нашего справочного склада. Дубль заказа невозможен, т.к. есть проверка по уникальности номера заказа +кабинет

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

Что касается дрейфа - ночью полностью сверяем остатки с 1с.

[alleku]

Понял, спасибо. Сверка раз в сутки как пояс безопасности логична, дрейф на единичных остатках иначе не выловить. Красивая схема, спасибо что поделились деталями.