Какую стратегию кэширования через Redis вы выбирали

Что проверяют

Был ли у вас реальный кэш в продакшене и понимаете ли вы его цену: устаревшие данные, гонки при инвалидации, нагрузка на базу в момент промаха. Следом обычно спрашивают, что будет с сервисом, если Redis упадёт.

Как отвечать

Отвечайте от своего проекта: какие данные кэшировали, почему эта стратегия, какой TTL, как сбрасывали, какой получили hit rate. Цифры нужны ваши. Если продакшен-опыта не было, так и скажите и разберите, что выбрали бы для конкретной задачи.

Стратегии, которые стоит уметь сравнить:

• cache-aside: сервис читает из Redis, на промахе идёт в базу и кладёт результат с TTL. Самый частый вариант. При записи ключ удаляют, а не перезаписывают, иначе параллельные обновления оставят в кэше старое значение;
• write-through: запись идёт в кэш и базу синхронно, чтение всегда тёплое, но запись медленнее;
• write-behind: пишем в кэш, в базу асинхронно. Быстро, но при падении данные теряются;
• refresh-ahead: горячие ключи обновляются до истечения TTL.

Детали на Go, которые выдают опыт. Клиент github.com/redis/go-redis/v9: промах приходит ошибкой redis.Nil, её отличают от ошибки сети. Одновременные промахи по одному ключу схлопывают через golang.org/x/sync/singleflight. К TTL добавляют случайный разброс, чтобы ключи не истекали разом. На вызовы ставят короткий таймаут через context, а при недоступности Redis идут в базу напрямую. В конфиге задают maxmemory и политику вроде allkeys-lru: по умолчанию стоит noeviction, и при заполнении памяти запись падает.

Где спотыкаются

Перечисляют стратегии из учебника без привязки к своим данным. Вопрос звучит как «вы выбирали», и ответ без проекта выглядит пересказом.

Считают любую ошибку Redis промахом. Тогда сбой сети тихо превращается в лавину запросов к базе.

Инвалидируют через Pub/Sub и считают это надёжным. Доставка там не более одного раза, отключившийся подписчик сообщение теряет, поэтому TTL остаётся страховкой.