Любой калькулятор стоимости в интернет-магазине опирается на одно и то же — актуальные данные о товарах. Цены, остатки на складах, свойства совместимости, технические параметры: если хотя бы один из источников содержит ошибку или обновляется с задержкой, калькулятор перестаёт быть инструментом продаж и превращается в источник проблем.
В этой статье разберём, как выбрать архитектуру хранения данных для калькулятора на базе 1С‑Битрикс. Рассмотрим три подхода, их плюсы и минусы, а также покажем, как мы решали эту задачу в проекте Макмарт.
Почему архитектура данных решает всё
Калькулятор в e-commerce — это не просто формула, а интерфейс между клиентом и каталогом. Покупатель видит цену, собирает комплектацию и принимает решение о заказе. Если данные неточные, устарели или медленно загружаются, доверие к сервису падает мгновенно.
Особенно критично это в B2B и сложных нишах: светотехника, мебельная фурнитура, инженерное оборудование. Здесь цена зависит от десятков параметров, а ошибка в одной позиции может обесценить весь заказ. Поэтому выбор архитектуры данных стоит ещё до начала разработки.
Три инструмента хранения данных в 1С‑Битрикс
Внутри 1С‑Битрикс есть три основных инструмента, которые можно использовать для хранения данных калькулятора. Важно не пытаться всё засунуть в один, а применять каждый по назначению.
Узнайте, каким должен быть современный калькулятор стоимости для интернет-магазина. Разбираем функции, интеграцию с CRM и 1С, ошибки разработки и способы увеличить конверсию.
Инфоблоки
Инфоблоки — стандартный способ хранить каталог. Они удобны для пользователей: контент-менеджер видит привычную форму, разделы, свойства, фото и цены. В калькуляторе инфоблоки хранят товары, их свойства, цены, остатки и зависимости.
Собственные таблицы и ORM D7
Через ORM D7 можно работать с собственными таблицами базы данных. Это даёт разработчику полный контроль над запросами и позволяет хранить служебные данные, которые не нужны в админке: предрасчитанные зависимости, индексы совместимости, кэшированные спецификации.
Highload-блоки
Highload-блоки лучше подходят для хранения большого количества однотипных записей и служебных данных: технические данные о черновиках, логи действий пользователя, история добавления расчётов в корзину. Сами черновики, с которыми работают менеджеры, удобнее держать в инфоблоках.
Три архитектурных подхода
Из этих инструментов можно собрать три разные архитектуры. Выбор зависит от размера каталога, сложности расчёта и ожидаемой нагрузки.
Подход 1. Всё внутри 1С‑Битрикс: инфоблоки + собственные таблицы + Highload‑блоки
Все данные калькулятора остаются в экосистеме 1С‑Битрикс. Товары и клиентские данные хранятся в инфоблоках, служебные выборки — в собственных таблицах через ORM D7, а логи и технические записи — в Highload-блоках.
Когда подходит
Каталог содержит до 10 000–20 000 позиций.
Логика расчёта не требует перебора огромных массивов.
Важна простота поддержки и знакомый интерфейс админки.
Команда уже умеет работать с API Битрикса.
Плюсы
Единая точка правды — данные хранятся в одном месте.
Минимум инфраструктуры и кода на поддержку.
Нативная интеграция с каталогом, скидками и остатками.
Быстрый старт без внешних зависимостей.
Минусы
При сложных фильтрах запросы к инфоблокам могут замедляться.
Высокая нагрузка на базу при большом трафике.
Сложные математические расчёты трудно выполнять в рамках ORM.
Рекомендация
Используйте этот подход, если у вас небольшой или средний каталог, и калькулятор не строится на тяжёлых вычислениях. Это самый экономичный и понятный вариант на старте.
Подход 2. Битрикс + Redis
Основные данные остаются в инфоблоках, а тяжёлые и часто запрашиваемые расчёты кэшируются в Redis. Важно понимать: Redis не заменяет основной источник данных, а используется как промежуточный слой кэширования, ускоряя повторяющиеся вычисления и выборки.
Когда подходит
Нужна высокая скорость без полного отказа от Битрикс.
Каталог среднего размера с активным трафиком.
Есть повторяющиеся сложные выборки, которые можно закэшировать.
Важна балансировка между стоимостью и производительностью.
Плюсы
Скорость отклика значительно выше, чем у чистого ORM.
Данные остаются в привычной экосистеме 1С‑Битрикс.
Простое масштабирование кэша по мере роста нагрузки.
Меньше инфраструктуры, чем у отдельного сервиса.
Минусы
Требуется продумать стратегию инвалидации кэша.
Нужна настройка Redis и мониторинг.
При кэшировании есть риск показать устаревшие данные.
Рекомендация
Если вы хотите сохранить удобство Битрикса и при этом ускорить работу калькулятора, начните с этого подхода. Он даёт большую часть эффекта отдельного сервиса при гораздо меньших затратах.
Подход 3. Отдельный сервис
Если каталог огромен, а расчёт требует сложной математики или перебора сотен параметров, стандартные запросы к инфоблокам становятся узким местом. В таком случае данные «выгружаются» в отдельную оптимизированную таблицу или внешний сервис.
Когда подходит
Более 50 000 товаров и сложная логика подбора.
Нужна экстремальная скорость расчёта.
Есть готовая команда для поддержки отдельного сервиса.
Калькулятор использует предварительно рассчитанные зависимости.
Плюсы
Высокая производительность даже под нагрузкой.
Возможность хранить уже предвычисленные данные.
Гибкость в выборе технологий сервиса.
Не зависит от ограничений API Битрикса.
Минусы
Необходимо настраивать синхронизацию с каталогом.
Риск рассинхронизации данных при сбоях.
Больше инфраструктуры и затрат на поддержку.
Требуется обработка событий изменения товаров в Битриксе.
Рекомендация
Этот путь оправдан, только если скорость и масштаб действительно критичны для бизнеса. Для большинства e-commerce проектов он избыточен.
Сравнение подходов
Чтобы выбрать правильную архитектуру, полезно свести варианты в сравнение по трём параметрам: скорость, простота и масштабирование.
ORM/D7: скорость 3/5, простота 5/5, масштабирование 2/5.
ORM/D7 + собственные таблицы: скорость 4/5, простота 3/5, масштабирование 4/5.
Битрикс + Redis: скорость 5/5, простота 4/5, масштабирование 5/5.
Отдельный сервис: скорость 5/5, простота 1/5, масштабирование 5/5.
Оценки условные и зависят от конкретной задачи, но они хорошо показывают общую логику: чем выше скорость и масштабируемость, тем сложнее поддержка.
Схема архитектуры
На схеме ниже показано, как распределяются роли между инструментами в каждом из подходов.
Клиент (браузер) → калькулятор на frontend → API 1С‑Битрикс → инфоблоки, собственные таблицы, Highload-блоки.
Клиент → калькулятор → API Битрикс + Redis для кэша → инфоблоки как источник правды.
Клиент → калькулятор → отдельный сервис → синхронизация с каталогом 1С‑Битрикс.
Если нужна визуальная диаграмма, её можно добавить в виде иллюстрации к статье.
Как выбрать подход для своего проекта
Выбор зависит от трёх факторов: размера каталога, сложности расчёта и ожидаемой нагрузки.
Мало товаров и простая логика — берите всё внутри Битрикс.
Тысячи товаров, сложные зависимости и высокая посещаемость — рассмотрите Битрикс + Redis.
Огромный каталог и уникальные требования к скорости — только отдельный сервис.
Главное — не усложнять там, где это не нужно. Часто компании переплачивают за отдельный сервис, хотя обычного кэширования и грамотных SQL-запросов было бы достаточно.
Наш опыт в проекте Макмарт
В проекте для компании Макмарт мы разрабатывали калькулятор LED-профилей. Задача была непростой: сотни профилей, десятки рассеивателей, блоки питания и комплектующие. Пользователь проходил пошаговый подбор, и на каждом шаге система должна была мгновенно предлагать только совместимые варианты.
Мы выбрали гибридный подход и использовали сразу три инструмента хранения данных, каждый по своему назначению.
Инфоблоки для клиентских данных и черновиков
Каталог профилей, рассеивателей, блоков питания, креплений и других комплектующих хранится в стандартных инфоблоках 1С‑Битрикс. Контент-менеджеры и менеджеры компании легко обновляют ассортимент, цены, остатки и свойства без участия разработчиков, поэтому данные в калькуляторе остаются актуальными.
Сами черновики расчётов, с которыми работают менеджеры, мы также храним в инфоблоках. Это даёт привычный интерфейс админки, гибкость настройки полей и удобную работу с записями через стандартные инструменты Битрикса.
Собственные таблицы и ORM D7 для служебных выборок
Часть данных, необходимых для быстрого подбора, вынесена в отдельные таблицы и работает через D7. Туда попадают предрасчитанные зависимости, индексы совместимости и другие служебные структуры, которые не нужны в админке, но критичны для скорости.
Такой подход снимает нагрузку с инфоблоков и позволяет выполнять сложные выборки напрямую. Для мгновенного подбора на ключевых шагах мы используем оптимизированные SQL-запросы, и среднее время отклика интерфейса обычно не превышает 100 мс.
Highload-блоки для технических данных и логов
В highload-блоках мы храним технические данные о черновиках, историю добавления расчётов в корзину и логи покупок. Они эффективно справляются с большим количеством однотипных записей и быстро отдают данные обратно в интерфейс.
Благодаря этому пользователь может сохранить расчёт, вернуться к нему позже, добавить в корзину или оформить заказ, а менеджер в любой момент видит полную историю действий клиента.
Результат: клиенты получают точный расчёт за секунды, менеджеры тратят меньше времени на ручную обработку заявок, а компания получает гибкую систему, которую удобно поддерживать и масштабировать.
FAQ
Когда использовать Highload-блок?
Highload-блок стоит выбирать, когда нужно хранить большое количество однотипных служебных записей: логи, историю действий, технические данные о черновиках. Если запись должна быть удобно доступна менеджеру в админке — лучше инфоблок.
Redis заменяет инфоблоки?
Нет. Redis — это слой кэширования, а не основной источник данных. Источником правды остаются инфоблоки или собственные таблицы. Redis только ускоряет доступ к тем данным, которые часто запрашиваются.
Когда нужен отдельный сервис?
Отдельный сервис нужен, когда каталог действительно большой (десятки и сотни тысяч товаров), логика расчёта сложная, и требования к скорости не позволяют решить задачу в рамках Битрикс. Для большинства проектов достаточно ORM/D7 или Redis.
Можно ли комбинировать подходы?
Да, и часто это самый практичный путь. Например, каталог в инфоблоках, служебные выборки в собственных таблицах, кэш в Redis, а логи в Highload-блоках. Главное — чётко разделить роли каждого инструмента.
Что дороже: Redis или отдельный сервис?
Отдельный сервис почти всегда дороже: нужна синхронизация, мониторинг, поддержка инфраструктуры и отдельная команда разработки. Redis дешевле и проще внедрить, особенно если он уже используется в проекте.
Частые ошибки
Брать слишком сложную архитектуру на старте проекта.
Хранить всё в инфоблоках, не замечая, что выборки тормозят.
Использовать Redis как основной источник данных вместо кэша.
Игнорировать инвалидацию кэша и получать устаревшие цены.
Выносить расчёты в отдельный сервис без реальной необходимости.
Чек-лист выбора архитектуры данных
Оцените реальный размер каталога и темпы его роста.
Проанализируйте, какие операции занимают больше всего времени.
Проверьте, можно ли ускорить текущие запросы без новой инфраструктуры.
Рассчитайте бюджет на поддержку отдельного сервиса или Redis.
Продумайте стратегию обновления данных и инвалидации кэша.
Правильная архитектура данных — это то, что отличает рабочий калькулятор от нерабочего. 1С‑Битрикс даёт гибкость, но важно понимать, когда достаточно стандартных инструментов, а когда пора подключать кэш или выносить расчёты в отдельный сервис.
Не гонитесь за отдельными сервисами ради красивого слова. Начните с простого, измерьте производительность и усложняйте архитектуру только там, где это действительно приносит бизнес-эффект. А если нужен надёжный партнёр для разработки калькулятора на 1С‑Битрикс — обратитесь к нам, мы уже прошли этот путь в проекте Макмарт.
Узнайте, как комплектатор товаров помогает увеличить конверсию интернет-магазина. Разбираем преимущества, кейс Макмарт, интеграцию с 1С-Битрикс и лучшие практики для B2B и e-commerce.
Почему прозрачный расчет стоимости повышает доверие клиентов? Разбираем кейс Макмарт и показываем, как калькулятор помогает увеличить конверсию и снизить количество ошибок.
-1-300x300.png%3F2026-08-06T11%253A50%253A36.251Z&w=3840&q=75)
