Как работает кэширование

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

Два ключевых параметра любого кэша:

  • TTL (Time to Live) — через сколько секунд запись считается устаревшей и удаляется
  • Cache invalidation — принудительное обнуление при изменении исходных данных

Уровни кэширования в e-commerce

Уровень Где Что кэшируется
CDN Edge-серверы (Cloudflare, Fastly) Статика: JS, CSS, изображения, HTML-страницы
Application cache Redis, Memcached Результаты запросов: рекомендации, цены, наличие
In-memory RAM сервиса Горячие данные с нулевой latency
Client-side LocalStorage, Cache API Контент для офлайн-работы, предзагрузка

Для платформы персонализации критичен application cache — именно там хранятся готовые векторы пользователей и предрассчитанные топы рекомендаций.

TTL в персонализации: компромисс актуальности и нагрузки

TTL = 0 мин   → каждый запрос к API, максимальная актуальность, высокая нагрузка
TTL = 5 мин   → баланс: рекомендации немного устаревают, нагрузка снижена в 10–20×
TTL = 60 мин  → подходит для статичных блоков (бестселлеры, новинки)
TTL = 24 ч    → только для редко меняющихся данных (категориальные топы)

Важно: персонализированный контент нельзя кэшировать по URL — нужна сегментация по пользовательскому идентификатору (cookie, session ID). Иначе пользователь B получит кэш пользователя A.

Кэш и A/B тесты

Один из частых конфликтов: CDN кэширует страницу без учёта принадлежности пользователя к группе теста. Результат — все посетители видят вариант A, хотя 50% должны видеть вариант B.

Решения:
— Использовать Vary: Cookie или Vary: X-AB-Group в заголовках ответа
— Запускать тест через серверный рендеринг с учётом группы до кэширования
— Вынести изменяемый блок из CDN-кэша и загружать асинхронно через JS

Типичные ошибки

  • Кэширование персонализированного контента как «общего» — пользователь получает чужие рекомендации
  • Слишком долгий TTL для динамичного ассортимента — рекомендованный товар уже закончился, но ещё отображается
  • Отсутствие стратегии инвалидации — изменение цены товара не распространяется до следующего TTL
  • Кэш без разогрева (cache warming) — после деплоя первые пользователи получают все ответы из источника, latency резко растёт