Как синхронизировать цены и остатки магазина с учётной системой

Уточните смысл остатка

Физическое количество на складе, свободное количество и доступность для продажи не всегда совпадают. Часть товара может быть зарезервирована, заблокирована или находиться на другом складе. Если сайт получает одно число без определения, разработчик вынужден угадывать смысл. Зафиксируйте формулу и владельца расчёта до выбора частоты обновления.

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

Назначьте владельцев полей

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

Выберите способ обновления по требованиям

Полная выгрузка проще для первичного наполнения и сверки, но может быть тяжёлой. Передача изменений сокращает объём, однако требует надёжно определять пропуски и порядок. Уведомление о событии может ускорить реакцию, но не отменяет проверку целостности. Комбинация изменений и периодической сверки часто удобна, если подтверждена возможностями систем.

Укажите допустимую задержку отдельно для каталога и подтверждения заказа. Обещание «в реальном времени» без измеряемого предела не помогает принять интеграцию. Записывайте время изменения в источнике и время успешного применения. Так видно, где возникло отставание: получение, очередь или обработка.

Защитите данные от повторов и старых сообщений

Используйте устойчивый идентификатор товара, а не название. Варианты размера и комплектации должны различаться так же, как в учётной системе. Повтор сообщения не должен создавать новую карточку или повторно уменьшать остаток. Для изменения храните версию или другой предусмотренный контрактом признак порядка; позднее старое сообщение не должно отменять новое.

Удаление и отсутствие поля опишите отдельно. Пустая цена может означать ошибку данных, а не команду установить ноль. Отсутствующий товар в частичной выгрузке не обязательно снят с продажи. Карта полей должна содержать эти значения и примеры, иначе даже успешный HTTP-ответ не гарантирует правильного обмена.

Предусмотрите покупку на границе изменений

Посетитель мог открыть карточку до изменения цены или продажи последней единицы. Перед окончательным подтверждением проверьте актуальные условия по выбранному процессу резервирования. Если стоимость изменилась, объясните это и запросите необходимое подтверждение. Не полагайтесь только на число, которое браузер прислал из старой страницы.

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

Учебный пример проверки обмена

В источнике товар меняется с десяти доступных единиц до восьми, затем до семи. Сообщение о восьми задерживается и приходит последним. Проверка должна подтвердить, что сайт сохраняет актуальную версию с семью, а повтор не создаёт побочного эффекта. Затем выгрузка сверки подтверждает совпадение идентификатора, цены и количества.

Добавьте отсутствующую валюту, неизвестный вариант товара и ошибку одной строки в пакете. Запишите, какие записи применились и какие требуют исправления. Успешный статус всей задачи без отчёта по ошибкам скрывает расхождения. Пример является тестовой моделью, а не описанием конкретного учётного продукта.

Организуйте эксплуатационный контроль

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

Как обрабатывать события об остатках, пришедшие не по порядку

В учебном обмене сначала получено новое значение остатка, затем задержавшееся старое. Простое правило «последний запрос побеждает» вернёт устаревшее число. В контракте нужны сопоставимые версии или другой предусмотренный источником способ определить актуальность; локальное время получения не заменяет версию данных.

Проверьте повтор пакета, пропуск промежуточного обновления и полную сверку. Отдельно согласуйте, что означает резерв и когда он влияет на доступное количество. Если источник не предоставляет достаточно сведений для безопасного применения событий, используйте документированную сверку текущего состояния. В журнале фиксируйте конфликт и действие оператора. Покупатель не должен видеть уверенное обещание наличия, которое система уже считает неподтверждённым.