Почему калькулятор на сайте показывает старую цену и как это исправить

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

Разберём, откуда берётся расхождение, какие слои кэша вообще существуют, что в них можно хранить, а что нельзя, и как выстроить обновление так, чтобы правка цены доезжала до клиента предсказуемо — без ручных просьб «почистить кэш».

Почему калькулятор показывает старую цену, если прайс уже обновлён?

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

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

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

Отдельная причина — неполная синхронизация. Каталог обновился, но не все потребители получили изменения: один сервис пропустил событие, второй упал во время выгрузки, третий работает на резервной копии. Внешне это выглядит как «сайт врёт», а внутри — обычная дыра в обмене данными.

Какие слои кэша стоят между прайсом и клиентом?

Кэш — это не одна сущность, а этажерка. И каждая полка живёт по своим правилам, со своим сроком жизни и своим способом сброса. Пока вы не видите всю этажерку, любая правка превращается в лотерею.

Браузер клиента и промежуточные прокси

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

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

Кэш на сервере и в сервисе расчёта

Следующий слой — серверный. Здесь кэш нужен по делу: он снимает нагрузку с каталога и ускоряет ответ калькулятора, которому данные нужны на каждый расчёт. Когда клиент двигает ползунок, никто не должен ходить в каталог заново.

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

Кэш внутри калькулятора: сохранённые расчёты

Третий слой — сам расчёт. Клиент собрал конфигурацию, получил сумму, отвлёкся, вернулся через час и видит прежние цифры. Иногда это ровно то поведение, которое нужно: человек продолжает работу с того места, где остановился.

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

Почему одного слоя недостаточно

Можно сколько угодно настраивать серверный кэш, но если браузер клиента держит страницу сутки, клиент всё равно увидит старое. И наоборот: идеальные заголовки кэширования не спасут, если сервис расчёта хранит копию прайса у себя.

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

Что можно кэшировать, а что нельзя?

Кэшировать стоит входные данные, а не итог, если итог зависит от чего-то персонального. Это правило снимает большинство споров о том, «можно ли хранить цены».

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

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

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

Как инвалидировать кэш при обновлении прайса?

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

Дальше работает приём, который снимает почти всю боль: версия как ключ. Данные каталога получают идентификатор состояния, и всё, что построено на них, ссылается на этот идентификатор. Новая версия — это новый ключ кэша; старый больше не запрашивается и исчезает сам, без ручного сброса и без риска, что где-то остался кусок прошлого.

Обновление лучше делать атомарно: сначала собрать новую версию, проверить её целостность, и только потом переключить потребителей. Если переключать по частям, возникает момент, когда часть страниц считает по новой цене, часть — по старой. Для клиента это выглядит как «сайт сошёл с ума», а для поддержки — как невоспроизводимый баг.

Полезно держать и предыдущую версию: она нужна для отката и для разбора инцидентов. Если новая выгрузка пришла с битыми данными, возврат к прошлому состоянию должен быть одной операцией, а не восстановлением из бэкапа под давлением.

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

Как пересчитывать уже открытые расчёты и коммерческие предложения?

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

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

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

Смежный вопрос — срок действия цены. Цена может быть объявлена заранее и вступать в силу с определённой даты, а может истекать. Если это не отражено в данных, калькулятор начнёт применять новую цену раньше срока или продолжит считать по просроченной.

Что показать клиенту, если данные устарели или API недоступен?

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

Недопустимый вариант один — молча выдать устаревшую цену как актуальную. Именно он превращается в скандал на этапе согласования, когда клиент приносит распечатку с сайта, а менеджер видит в системе другую сумму.

Отдельно продумывают заявку. Если учётная система недоступна, заявка не должна исчезать: она сохраняется с признаком «не передана» и уходит повторно. Клиент при этом видит подтверждение, потому что свою часть работы он выполнил.

Как проверить, что кэш не врёт?

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

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

Затем — сверка сумм. Один и тот же набор параметров прогоняют через калькулятор и через эталонный расчёт, а расхождение объясняют до запуска. Если объяснить не получается, значит логика живёт в двух местах, и это архитектурная проблема, а не настройка кэша.

И последнее — журнал. Без записи о том, какие данные и какая версия участвовали в конкретном расчёте, разбор инцидента превращается в гадание. Логировать стоит не только ошибки, но и факт выдачи данных: кто, что и когда запросил.

С чего начать, если прайс пока в Excel?

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

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

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

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

Частые вопросы