В чём проблема “каждый раз новый результат”

Кеш эффективен, когда есть повторяемость. Если результат намеренно меняется, повторяемости почти нет, и кеш перестаёт быть экономически выгодным.

1) Низкий hit rate и взрыв ключей

Типичная ситуация:

• ключ зависит от множества параметров + случайности + времени

• каждый запрос создаёт новый ключ

Последствия:

• hit rate близок к нулю

• Redis забивается мусорными ключами

• растёт стоимость сериализации/десериализации

2) Сложная семантика “правильности”

Если ответ меняется каждый раз:

• сложно определить, что именно кешировать

• сложно валидировать консистентность

• трудно объяснить клиентам, почему “вчера было так, а сейчас иначе” (если это важно)

3) Сложности с инвалидацией и гонками

Даже при коротком TTL остаются проблемы:

• гонки при одновременной генерации (thundering herd)

• непредсказуемые пики пересчёта

Определение: Thundering herd — когда много запросов одновременно запускают пересчёт из-за промаха кеша.

4) Рабочие стратегии вместо кеша “полного ответа”

Кешировать “кандидатов”, а не итоговую выдачу

Например:

• хранить пул id подходящих объектов (кандидатов)

• в запросе быстро выбирать/перемешивать/ранжировать

Ограничить энтропию выдачи

Если бизнес допускает:

• менять только часть выдачи (например, 20% ротируется)

• фиксировать выдачу на короткое окно времени (например, на 30-60 секунд)
  Это резко улучшает повторяемость и делает кеш полезным.

Кешировать промежуточные вычисления

• тяжёлый расчёт “кто подходит”

• быстрый расчёт “в каком порядке показать”

5) Защита от перегрузки

Даже без “полезного кеша” можно кешировать:

• rate limit решения

• “последний успешный результат” (stale) для деградации

• блокировку пересчёта (singleflight/lock)

Вывод

При “всегда новом” результате кеш полного ответа обычно не работает: низкий hit rate, взрыв ключей, сложная консистентность. На практике кешируют кандидатов/части ответа и тяжёлые промежуточные вычисления, а финальную вариативность делают дешёвой.