«Быстроном»: как мы уложили 6 миллионов скидок в Битрикс и не убили сервер

  • Интернет магазин
«Быстроном»: как мы уложили 6 миллионов скидок в Битрикс и не убили сервер
«Быстроном»: как мы уложили 6 миллионов скидок в Битрикс и не убили сервер

Контекст

О клиенте

«Быстроном» — региональная сеть супермаркетов с 23 магазинами в Новосибирске, Бердске, Искитиме, Барнауле, Бийске и Томске. Ассортимент — более 20 000 товарных позиций. После редизайна сайта встала задача не просто показать каталог, а автоматически синхронизировать цены, остатки и, что самое важное, акции — с привязкой к каждому конкретному магазину. Источник всех данных — ERP-система Microsoft Dynamics AX (Axapta), которая много лет используется в компании.

23 магазина
Новосибирск, Бердск, Искитим, Барнаул, Бийск, Томск
20 000+ товарных позиций
Автоматическая синхронизация
Цен, остатков и акций по каждому магазину
Microsoft Dynamics AX (Axapta)
Источник всех данных — ERP-система

Задача: скидки, которые не умеет Битрикс

Стандартный функционал «коробочного» Битрикса не покрывал сценарий клиента. Вот что требовалось:

  • Передавать из Axapta две цены на один товар: обычную и дисконтную (скидочную).
  • Привязывать акцию не просто к товару, а к конкретному магазину (или списку магазинов).
  • Ограничивать количество наборов, которые можно купить по акции.
  • Автоматически создавать отдельный раздел каталога под каждую акцию на время её действия.

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

В Axapta уже жила сложная логика: отдельные прайсы, промо-периоды, множество правил. Всё это нужно было «переложить» на сайт так, чтобы он работал быстро и без сбоев.

Решение: оркестратор, трансформация и кэш

Как мы уже писали ранее - была спроектирована система, которая состоит из четырех ключевых слоев:

Приём данных

Axapta отправляет JSON-пакет с готовыми ценами (со скидкой) и массивом условий-правил. Данные проходят через API-шлюз.

Оркестрация

Собственный оркестратор управляет последовательностью загрузки: сначала категории, затем товары, потом цены, остатки и только после этого — акции. Это гарантирует целостность данных.

Трансформация

На этом этапе мы запускаем многоступенчатый алгоритм, который превращает сырые правила Axapta в сущности скидок Битрикса. Это была самая кастомная часть работы

Кэширующий слой

Готовые финальные цены со скидками мы сохраняем в Valkey. Это позволило не пересчитывать скидки при каждом запросе пользователя, а отдавать уже посчитанный результат.

Команда и сроки

Проект длился около месяца, в комфортном темпе, без перегрузок.

С нашей стороны в проекте были задействованы:

  • Технический директор
  • Архитектор
  • Бэкенд-разработчик
  • Менеджер проекта
  • Тестировщик

Со стороны клиента — только разработчик Axapta и технический директор.

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

Сложности, которые нас удивили

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

  • Тяжёлая генерация. Внутренние механизмы Битрикса не рассчитаны на такой объём — процесс создания скидок сильно тормозил.
  • Расчёт на витрине. При попытке посчитать финальную цену для каждого товара с учётом всех акций сайт мог просто «лечь».
  • Инвалидация кэша. Когда клиент обновлял акции, кэш в Valkey устаревал — и мы спешно дорабатывали механизм сброса, чтобы пользователь всегда видел свежие цены.

Как мы это победили

Мы применили три главных приёма:

  • Агрессивное кэширование — стали кэшировать не промежуточные данные, а уже готовые цены со скидками. Это избавило публичную часть от тяжёлых расчётов.
  • Оптимизация запросов — переписали самые тяжёлые SQL-выборки, чтобы база данных быстрее отдавала нужные строки даже при 6 млн записей.
  • Ручная верификация — каждый чек сверяли вручную с витриной магазина и с логами выгрузки. Это помогло отловить ошибки, которые не ловили автотесты.

Результаты: технический фундамент для роста

Сайт только запущен, поэтому бизнес-показатели (конверсия, средний чек) пока не изменились — им нужно время, чтобы набрать статистику. Но теперь маркетологи «Быстронома» могут запускать любые акции, не думая о том, ляжет ли сайт. Система готова к масштабированию.

Выводы и уроки

Тщательный сбор требований — наше всё
Мы ещё раз убедились, что нельзя полагаться на «примерные» данные. В ритейле объемы всегда оказываются больше, чем кажется. Мы всегда запрашиваем у клиента реальные выгрузки и проводим предварительный анализ.
Ранний MVP спасает
Если бы мы начинали заново, мы бы сделали максимально простую версию работы со скидками в первую же неделю. Это позволило бы выявить «эффект 6 миллионов» на раннем этапе и скорректировать архитектуру без спешки.
Кэширование — не опция, а необходимость
Без Valkey и продуманной стратегии хранения готовых цен публичная часть сайта просто не выдержала бы нагрузки.
Коммуникация с клиентом — ключ к успеху
Совместный дебаг и оперативное согласование правок помогли нам уложиться в сроки и избежать взаимных претензий.

Реализованные проекты (5000

Заказать проект

Digital-агентство AiR
Орджоникидзе, 38 630099 Новосибирск
+7(383)3830717 sale@airws.ru