Кейс из практики: интеграция с маркировкой «Честный знак» и архитектурное решение не полагаться только на внешний сервис проверки кодов.
Честный знак и один баг, который чуть не остановил продажи
Года полтора назад мне достался магазин, который продавал БАДы и собирался перейти на маркировку «Честный знак». Задача звучала скучно: подключить проверку кодов при приёмке и сборке заказа. На деле там оказалась одна деталь, из-за которой я до сих пор привожу этот кейс как пример, когда архитектурное решение важнее самого кода.
Стандартный путь такой: магазин работает через Saby (бывший СБИС), и проверка валидности кода маркировки идёт через него же. Товар приехал, отсканировал код, система сказала да или нет, поехали дальше. Просто, понятно, и почти все так делают.
Я полез в документацию Saby перед тем, как писать код, скорее по привычке, чем по необходимости. И наткнулся на формулировку, из которой следовало: ответ сервиса о валидности кода не гарантирован мгновенно и не гарантирован однозначно в каждый момент времени. Технически это нормально, у любого внешнего сервиса бывают задержки и сбои. Но если магазин полностью завязан на этот единственный источник правды, а сервис в моменте недоступен или отвечает неоднозначно, приёмка товара и сборка заказов встают. На складе БАДов это особенно неприятно, там сроки годности и партии, простой стоит реальных денег.
Решение получилось простым, хотя до него нужно было дойти. Я добавил дополнительный уровень проверки на своей стороне: магазин ведёт собственный реестр отсканированных и уже проверенных кодов, не полагаясь каждый раз заново на внешний ответ. Если Saby недоступен в моменте, система не встаёт колом, а работает по последнему известному статусу и помечает операцию на донастройку задним числом. Ничего революционного, обычный defense in depth, просто применённый не к паролям и не к доступам, а к логистике маркированного товара.
Дальше пошла рутина, которая тоже стоит упоминания, потому что из неё обычно и складывается реальная стоимость интеграции. Я декомпозировал задачу на этапы: приёмка товара с проверкой кода, оплата, сборка заказа со сканированием каждой позиции, передача в курьерскую службу. На это ушло около сорока пяти нормочасов, и большая часть времени утекла не на код, а именно на продумывание, что происходит на каждом шаге, если что-то пойдёт не так. Отдельно спроектировал интерфейс сканирования для кладовщика, потому что человек с терминалом на складе не должен думать о том, как устроена система изнутри, ему нужно просто навести сканер и увидеть зелёный или красный экран.
Если вы продаёте маркированные товары через свой сайт и у вас вся логика завязана на один внешний сервис проверки, стоит хотя бы задать себе вопрос: что произойдёт, если этот сервис в какой-то момент ответит не так, как вы ожидаете. Иногда ответ в духе «ничего страшного, подождём» вполне разумен. А иногда это дыра, через которую в пиковый день остановится весь склад.
Если хотите проверить, как у вас устроена интеграция с маркетплейсами и маркировкой, можно обсудить это на отдельной странице про такой аудит.