Интернет-магазин с актуальными остатками из нескольких источников

Актуальные остатки — одна из самых сложных частей интернет-магазина, если товар приходит со склада, 1С, ERP, поставщиков и ручных таблиц одновременно. Ошибка здесь бьёт не только по UX: она создаёт отмены, нагрузку на менеджеров, недоверие клиентов и проблемы с рекламными фидами. Ниже — архитектура, которая работает при большом каталоге и нескольких источниках.

Контекст задачи: не «залить Excel», а построить слой данных

В проекте каталога для HoReCa мы работали с ассортиментом разных брендов и типов продукции. На публичном сайте Crystal Group видны 79 брендов, склад 5 000 м² и более 1 537 оснащённых объектов. При таком масштабе ручное обновление карточек перестаёт быть надёжным. Поэтому сайт должен не хранить случайные копии остатков, а собирать и нормализовать данные по правилам.

Каноническая модель товара

Внутренний product_id — стабильный идентификатор сайта.
SKU/артикул производителя — основной ключ сопоставления.
EAN/штрихкод — дополнительный ключ, когда артикулы источников различаются.
Offer_id — конкретная комбинация варианта, склада, цены и поставщика.
Источник, время обновления, срок поставки и качество данных хранятся отдельно.

Нельзя объединять товары только по названию: «бокал 350 мл» у двух брендов — разные позиции. Нормализуем регистр, пробелы и разделители, но сохраняем исходные значения для диагностики.

Как выбирается актуальное наличие

Ситуация	Правило
Товар есть на собственном складе	Показываем «в наличии», количество или диапазон — в зависимости от коммерческой политики.
Нет на складе, есть у поставщика	Показываем «под заказ» и подтверждённый срок, а не зелёный статус «в наличии».
Источники конфликтуют	Побеждает источник с более высоким приоритетом и свежим timestamp; конфликт пишется в журнал.
Данные устарели	После TTL статус автоматически меняется на «уточняйте», чтобы не продавать старое наличие.
Идёт оформление заказа	Резерв уменьшается отдельно от физического остатка и снимается по таймауту или отмене.

Поток синхронизации

Получить данные через API, выгрузку, SFTP, webhook или очередь сообщений.
Провалидировать схему: обязательные поля, типы, отрицательные остатки, дубли.
Нормализовать единицы измерения, артикулы, валюту и статус поставки.
Сопоставить offer_id с карточкой; неизвестные позиции отправить в очередь ручного разбора.
Применить правило приоритета и обновить только изменившиеся записи.
Перестроить поисковый индекс, фид и кеш затронутых товаров.
Записать результат синхронизации: вход, изменения, ошибки, длительность и источник.

Пакетная загрузка или события

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

Надёжность важнее частоты

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

Мониторинг и критерии приёмки

Доля автоматически сопоставленных позиций и список исключений.
Возраст последнего успешного обновления по каждому источнику.
Количество конфликтов, ошибок и повторных попыток.
Расхождение контрольной выборки между источником и сайтом.
Время от изменения в учётной системе до изменения карточки.
Доля отмен из-за отсутствия товара и обращения «есть ли в наличии?».

SEO и рекламные системы

Статус наличия передаём в schema.org Product/Offer и товарные фиды. Страницы временно отсутствующих товаров не удаляем автоматически: сохраняем контент, аналоги и ожидаемый срок. Если позиция снята навсегда, используем осмысленный 301 на ближайший аналог или категорию, а не массовый редирект на главную.

Что получает бизнес

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