Как кэшировали данные пользователей с использованием Redis и какой клиент применяли?

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

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

Как отвечать

Стройте рассказ вокруг своей системы и её цифр: выдуманный процент попаданий рассыпается на первом уточнении. Опорные точки:

• клиент: чаще всего StackExchange.Redis с одним ConnectionMultiplexer на приложение, зарегистрированным как singleton. Если работали через абстракцию, назовите IDistributedCache из пакета Microsoft.Extensions.Caching.StackExchangeRedis или HybridCache, появившийся вместе с .NET 9: он добавляет локальный уровень и защиту от одновременной загрузки одного ключа;
• паттерн: обычно cache-aside, приложение читает из кэша, при промахе идёт в базу и кладёт результат с TTL;
• формат: ключи вида user:{id}:profile, сериализация через System.Text.Json, строка с JSON или хэш, если поля обновляются по отдельности;
• инвалидация: после записи в базу ключ удаляется, а не перезаписывается, иначе две параллельные записи могут оставить в кэше старую версию;
• результат: доля попаданий, снижение нагрузки на базу, время ответа до и после. Только свои реальные числа.

Все вызовы асинхронные: StringGetAsync, StringSetAsync. Отдельно скажите, что в кэш не кладёте: пароли, токены и лишние персональные данные.

Если Redis вы трогали только в учебном проекте, так и скажите и объясните, что сделали бы иначе в проде: как выбрали бы TTL, как подготовились к недоступности Redis. Честный небольшой опыт лучше придуманного большого.

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

Создают ConnectionMultiplexer на каждый запрос. Он тяжёлый и рассчитан на переиспользование, под нагрузкой это заканчивается исчерпанием соединений.

Считают TTL решением проблемы устаревших данных. TTL ограничивает срок жизни ошибки, а корректность обеспечивает удаление ключа при изменении.

Не думают о падении Redis. Кэш должен быть необязательным: при таймауте запрос идёт в базу, а не отдаёт пользователю 500.