Смерть от таймаута: как на самом деле работает синхронизация цен и остатков в Хорошопе

Я занимаюсь интеграциями и веб-разработкой больше семи лет. За это время я выучил одно железное правило: красивое API в документации и реальный обмен данными в продакшене — это две абсолютно разные вселенные. На бумаге всё летает, запросы уходят за миллисекунды, а в логах царит идеальный порядок. В реальности же у вас на носу Черная пятница, пять поставщиков с кривыми прайсами, а разъяренный клиент обрывает телефон, потому что покупатели прямо сейчас выгребают со склада айфоны по цене чехлов из-за сбоя в выгрузке.

В ноябре прошлого года мы наступили на эти грабли в полный рост. К нам пришел клиент с магазином автозапчастей на Хорошопе. 18 420 активных позиций в каталоге. Поставщики обновляли свои остатки и прайсы каждые два-три часа. Мы написали чистый, академически правильный код под API. На тестовой базе с сотней товаров всё работало как швейцарские часы. Но когда мы запустили систему на реальных данных в боевом режиме, сервер Хорошопа через десять минут начал стабильно отдавать 429 ошибку (Too Many Requests). Лимиты платформы на количество запросов в минуту просто заблокировали наш IP. Синхронизация встала.

Почему «чистый» API — это опасная иллюзия

Когда вам обещают мгновенное автообновление цен horoshop, обычно умалчивают о суровой технической реальности. Платформа Хорошоп делит серверные ресурсы между тысячами магазинов. Чтобы один кривой скрипт не положил всю систему, разработчики платформы жестко ограничивают частоту запросов. Если вы попытаетесь обновить базу в 15 000 товаров, отправляя каждый товар отдельным POST-запросом, вас заблокируют на первых же сотнях позиций.

Другая проблема — это качество исходных данных. Поставщики редко присылают идеальные прайсы. В их XML-файлах постоянно ломается кодировка, дублируются артикулы, появляются отрицательные остатки или цены, равные нулю. Если ваша интеграция horoshop не умеет фильтровать этот мусор на лету, она начнет пихать ошибки напрямую в базу сайта. В лучшем случае скрипт просто упадет. В худшем — вы продадите дорогой товар за бесценок.

Как мы решили проблему: гибридный подход с CSV-резервом

После того факапа с автозапчастями мы полностью переписали архитектуру наших интеграций. Мы поняли, что надежная horoshop api синхронизация не может существовать без плана «Б». Чистый API хорош для точечных изменений, но для массовых обновлений нужен совершенно другой подход.

Мы внедрили трехступенчатую систему, которая теперь работает во всех наших проектах. Первый этап — это дельта-кэширование. Наш скрипт не пытается залить на сайт весь прайс целиком. Зачем переписывать карточки всех 18 тысяч товаров, если за последний час цена изменилась только у двух сотен? Скрипт скачивает прайс поставщика, сравнивает его с предыдущим состоянием базы данных, вычисляет разницу (дельту) и отправляет в Хорошоп только те позиции, где реально изменилась цена или количество. Это снижает нагрузку на серверы на 90%.

Второй этап — пакетная отправка. Мы группируем измененные товары в пакеты по 50-100 штук и отправляем их одним запросом. Это позволяет укладываться в любые лимиты API без потери скорости.

Третий этап, наш главный спасательный круг — это автоматический CSV-fallback. Если API Хорошопа по какой-то причине недоступно, временно заблокировано или объем обновлений слишком велик (например, поставщик устроил глобальную распродажу и поменял цены сразу на 10 000 товаров), система мгновенно переключается в резервный режим. Скрипт генерирует кастомный CSV-файл импорта, отформатированный строго под требования платформы, и загружает его через специальный импортный шлюз Хорошопа. Админка обрабатывает такие файлы в фоновом режиме без жестких лимитов на запросы. Это гарантирует, что остатки горошоп обновятся в любом случае, даже если внешние каналы связи штормит.

Три правила выживания для владельца интернет-магазина

Если вы планируете автоматизировать работу с прайсами, не верьте разработчикам, которые обещают настроить всё «за два часа через стандартный коннектор». Спросите их напрямую: как система будет вести себя при превышении лимитов API? Что произойдет, если прайс поставщика скачается наполовину битым? Как реализовано логирование ошибок?

Наш опыт показывает: лучше стабильное обновление раз в час с детальным логом ошибок, чем «моментальный» реалтайм, который падает при первой же нагрузке. Вы должны четко знать, почему конкретный товар не обновился. В 95% случаев проблема кроется в человеческом факторе на стороне поставщика — кто-то забыл указать артикул или добавил лишний пробел. Хорошая интеграция должна ловить такие ошибки, пропускать проблемный товар, отправлять уведомление в Телеграм вашему менеджеру, но продолжать обновлять остальные позиции.

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

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