Почему кэш цен показывает покупателям устаревшие данные?
Потому что страница, API или CDN отдают покупателю заранее сохранённую копию цены, а не запрашивают её заново из базы или товароучётной системы. Пока не истёк срок жизни кэша или не сработала принудительная инвалидация, покупатель видит старую сумму, даже если в каталоге цена уже изменена.
Практическое решение строится в четыре шага. Сначала аудит всех слоёв: кэш браузера, CDN и обратного прокси, серверный кэш страниц, Redis или Memcached, кэш внутри приложения и очередей. Затем для каждого слоя задаётся обоснованный TTL: для цен он обычно измеряется минутами, а не часами, а для акционных и персональных скидок — секундами или вообще отключается. После этого настраивается событийная инвалидация: изменение цены, старт или конец акции, смена курса валюты, обновление прайса поставщика должны сбрасывать конкретный ключ, а не весь кэш целиком. Завершает работу версионирование ключей, прогрев после сброса и мониторинг расхождений между ценой в кэше и ценой в базе.
Ключевой технический нюанс: кэшировать по адресу страницы нельзя, если цена зависит от пользователя — уровня лояльности, региона, валюты или персональной скидки. В таких случаях применяют сегментный кэш с ключом по группе покупателя, отдают базовую цену с пересчётом на клиенте по защищённому API или переносят расчёт финальной суммы на этап оформления заказа с обязательной серверной проверкой перед оплатой. Отдельно стоит закрыть риск рассинхронизации с 1С или ERP: если обмен идёт по расписанию, кэш не должен жить дольше интервала выгрузки.
Внедрение такой схемы обычно занимает от нескольких дней до двух недель и включает настройку инвалидации, тесты на реальных сценариях скидок и контрольный дашборд по расхождениям цен. Если нужен предсказуемый результат без правок вручную, оставьте заявку — проведём аудит текущего кэширования, соберём карту слоёв и настроим обновление цен так, чтобы покупатель всегда видел актуальную сумму.