Почему Prom ложится на 10 000 товаров, и как мы перестали терять деньги на обновлениях

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

Вот тут стандартная схема дает трещину. А потом с грохотом ломается.

История одного вторника: минус 18 000 гривен до обеда

В ноябре прошлого года ко мне пришел владелец магазина сантехники и отопительного оборудования. База — 14 200 активных SKU на Prom.ua. Поставщиков четверо. Двое присылают остатки в CSV на FTP раз в три часа, один отдает корявый XML по ссылке, четвертый просто сбрасывает прайс в Telegram-канал каждое утро.

Схема у клиента была классическая: менеджер вручную скачивал файлы, сводил их в огромную таблицу через ВПР, генерировал итоговый YML и скармливал его в стандартный импорт Prom. На все уходило полтора часа в день. Терпимо? До определенного момента.

Во вторник один из импортеров поднял цены на европейские насосы и котлы на 11%. Курс качнулся, прайс изменился в 09:15. Менеджер, как назло, застрял в пробке и запустил файл только к одиннадцати. А дальше сработала физика маркетплейса: файл на 14 тысяч строк с полным деревом категорий встал в общую очередь импорта Prom. Пром честно крутил шестеренки, пока его внутренний парсер переваривал мегабайты XML-разметки.

Импорт завершился в 14:40. К этому времени конкуренты уже выставили новые ценники. А у нашего клиента роботы-парсеры перекупов и живые покупатели смели семь котлов и тридцать две насосные группы по старому прайсу. Чистый кассовый разрыв на разнице цен за полдня составил 18 400 гривен. Отменять заказы — резать рейтинг магазина, который набивали годами. Отгружать — работать в жесткий минус.

Анатомия затыка: почему стандартный импорт душит масштаб

Большинство предпринимателей искренне уверены, что если файл валидный, то система обязана проглотить его мгновенно. Это иллюзия.

Когда вы отправляете на платформу монолитный файл на 10k+ товаров, происходят три вещи:

Во-первых, вы грузите сервер абсолютно лишней работой. Если из 10 000 товаров цена поменялась у 150 штук, а остаток обнулился у сорока — зачем заставлять базу перечитывать оставшиеся 9 810 строк с их длинными описаниями, характеристиками и ссылками на картинки? Это дикий оверхед.

Во-вторых, очередь. В пиковые часы тысячи продавцов одновременно шлют свои фиды. Ваш файл встает за фидом магазина с 80 000 чехлов для телефонов. Вы ждете часами. В этот период оперативное обновление цен на prom превращается в лотерею.

В-третьих, обрывы сессий. Тяжелые выгрузки обожают падать по таймауту. Строка 8 412 содержала скрытый непечатный символ от кривого 1С поставщика — и весь импорт встал колом на середине. Половина позиций обновилась, вторая половина осталась со вчерашними данными. Вы даже не сразу поймете, где именно случился разрыв.

Как должна работать взрослая синхронизация

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

Настоящая автоматизация prom интернет-магазин выводит на принципиально другой уровень надежности только тогда, когда в архитектуре появляется промежуточный слой нормализации данных. Как это устроено у нас на практике:

1. Локальный дифференциальный анализ (вычисление дельты). Наш сервис забирает остатки и прайсы поставщиков в любых форматах (API, Google Таблицы, CSV, XML), приводит их к единому стандарту и сравнивает с текущим слепком базы. Если у товара артикул X цена была 500 и осталась 500, система выбрасывает его из пакета обновлений. На Prom уходит только «дельта» — исключительно те 50, 100 или 300 позиций, где зафиксировано реальное движение.

2. Прямая работа через REST API Prom.ua пачками (batches). Вместо тяжелых файловых очередей мы используем пакетное обновление через официальные эндпоинты API. Пакеты по 100 товаров залетают в систему за доли секунды. Вся витрина на 15 000 SKU пересчитывается без постановки магазина на паузу.

3. Умный троттлинг. У API есть лимиты на частоту запросов. Превысите — получите ошибку 429 (Too Many Requests) и временный бан. Скрипт обязан мягко регулировать поток: притормаживать при пиковых нагрузках и ускоряться, когда канал свободен.

Когда остатки prom автообновление получают по такой схеме, задержка между изменением стока у поставщика и сменой статуса на маркетплейсе сжимается с нескольких часов до 3–7 минут. Исчезает сам феномен продажи воздуха, когда клиент покупает товар, которого уже полчаса как нет на складе.

Реальность против красивых обещаний

Полноценная синхронизация склада prom — это не универсальный плагин за 20 долларов из маркетплейса расширений. Универсальные модули пишутся под идеальный мир, где поставщики отдают идеальные файлы с идеальными артикулами. В жизни такого мира не существует.

Один поставщик дублирует артикулы. Другой внезапно меняет кодировку с UTF-8 на Windows-1251. Третий ставит в поле остатка текст «много» вместо цифры. Если ваш скрипт не умеет ловить эти фокусы до того, как они сломают выгрузку, бизнес продолжит буксовать.

Мы в GuardLabs занимаемся именно этой грязной инженерной изнанкой. Мы строим индивидуальные отказоустойчивые связки, которые без сбоев крутят каталоги от 5 000 до 50 000 товаров, объединяют хаотичные источники и берут на себя контроль ошибок. Если вы устали от вечно зависающих файлов, краснеющих менеджеров и кассовых потерь из-за несвоевременных правок, посмотрите наше решение: Автообновление остатков и цен на Prom для больших каталогов. Мы подключаем систему под ключ, настраиваем правила переоценки под ваш бизнес и гарантируем, что витрина перестанет зависеть от человеческого фактора.