📂 Кейс: кэш спас скорость — и чуть не убил согласованность цен

🏢 Контекст:

Онлайн-аптека, 1,5 млн артикулов. Сервис каталога отдаёт карточку товара. После кэша в Redis 95-й перцентиль упал с 420 мс до 40 мс. Бизнес доволен. Через две недели — жалобы: в корзине одна цена, на оплате другая.


😬 Проблема:

Аналитик в ТЗ написал: «Кэшировать ответ карточки товара на 24 часа». Разработчики закэшировали весь ответ, включая поле «цена». Маркетинг обновил цены в БД в 09:00, пользователи до следующего дня видели старую цену в каталоге; при оформлении цена бралась из актуальной таблицы заказа — расхождение.


🔍 Что сделали:

1. Разделили кэшируемые поля: статика (название, фото) — долгое время жизни; цена — короткое (60 сек) или отдельный ключ по артикулу
2. Добавили сброс кэша по событию «цена изменилась» из админки
3. В контракт прослойки для фронта: на шаге оформления пересчёт цены с сервера, интерфейс показывает «цена обновлена» при расхождении
4. В ТЗ явно: «источник правды цены при оплате — сервис ценообразования, не кэш каталога»


✅ Результат:

Жалобы исчезли. 95-й перцентиль каталога — 55 мс (чуть выше, но в рамках НФТ). Аналитик добавил в шаблон ТЗ секцию «политика кэширования по полям».


💡 Выводы:

▫️ Кэш — архитектурное решение с бизнес-последствиями, не только про скорость
▫️ В ТЗ указывай: что кэшируем, срок жизни, сброс, что нельзя кэшировать на критичном пути
▫️ «Согласованность цены» — НФТ, которое ломается тихо