Как использовать кеширование в системах, где ответы не повторяются для одного и того же пользователя?

Question

Если полный ответ уникален, кешируют не “ответ целиком”, а его части: справочники, настройки, права, данные профиля, результаты тяжёлых подзапросов или промежуточные вычисления. Часто помогает кеш на уровне “строительных блоков”: отдельные сущности по ключу, а итоговый ответ собирается из них. Можно кешировать не данные, а “защиту от перегрузки”: лимиты, локальные prefetch, короткий TTL на часто запрашиваемые компоненты. Ещё один вариант — кешировать отрицательные результаты (например, “нет данных”) и использовать stale-данные при временных сбоях.

YeaHub · Accepted Answer

Почему кеш возможен даже при “уникальных ответах”Уникальность итогового ответа не означает, что все вычисления внутри него уникальны. Обычно есть общие фрагменты, которые повторяются между пользователями или между запросами одного пользователя.1) Кеширование по уровням: “части ответа” вместо “ответа”Вместо ключа вида cache:user::full_response выбирают ключи для компонентов:справочники (countries, currencies, categories)настройки/фичи (feature_flags)профиль пользователя (user_profile)права/роли (user_permissions)часто используемые сущности по id (товар, отель, город)Сборка ответа тогда становится:взять несколько кусочков из кеша/БДсклеить в ответ2) Кеш промежуточных вычисленийЕсли есть дорогая операция (например, расчёт скоринга/фильтров):кешируйте результат этой операции на короткий TTLключ строится по входным параметрам, а не по пользователю целикомОпределение: Memoization — запоминание результата функции по входам, чтобы не считать повторно.Пример идеи ключа:score::3) Кеш “на чтение сущностей” + локальная дедупликация запросовЧастая проблема: несколько горутин одновременно запрашивают один и тот же ресурс.Решение:кеш сущностей в Redis с TTLдедупликация “в полёте” (singleflight) внутри сервисаПример singleflight (коротко):import "golang.org/x/sync/singleflight" var g singleflight.Group func getHotel(ctx context.Context, id string) (any, error) { v, err, _ := g.Do("hotel:"+id, func() (any, error) { // 1) попробовать Redis // 2) иначе БД // ... детали опущены return fetchFromDB(ctx, id) }) return v, err } 4) Кеширование “негативных” и “частичных” результатовИногда полезно кешировать:“нет данных” (чтобы не долбить БД при пустых выдачах)частичный результат (например, только список id, а детали догружаются отдельно)Важно:TTL для негативного кеша обычно короткий, чтобы не “залипнуть” на пустоте5) Stale-while-revalidate и защита SLAОпределение: Stale-while-revalidate — можно отдать слегка устаревшие данные быстро, а обновление сделать в фоне.Подход:при истечении TTL не блокировать пользователя долгим пересчётомотдавать “последнее значение”, а пересчёт запускать асинхронно6) Практические правила, чтобы кеш не стал проблемойизмеряйте hit rate и latencyзадавайте разумные TTL и лимиты размерапродумывайте инвалидацию: TTL + события, если есть стрим измененийизбегайте “кеша на миллионы уникальных ключей” без ограничений (память улетит)ВыводЕсли ответы уникальны, кешируют не ответ целиком, а переиспользуемые части и промежуточные вычисления, плюс применяют дедупликацию запросов и stale-стратегии. Это снижает нагрузку и стабилизирует latency даже без повторяемости полного ответа.