Как ты добавишь кеш в сервис
Вопрос
Каталог товаров тормозит под нагрузкой. Как бы ты добавил кеширование и какие проблемы учёл?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Сначала измерить: какие запросы горячие, доля чтений и записей
Cache-aside в Redis с TTL, ключи с понятной схемой (product:42)
Инвалидация при изменении: удалять ключ, учитывать производные ключи (списки)
Cache stampede: блокировка на пересчёт, объединение запросов, jitter к TTL
Лимит памяти и политика вытеснения allkeys-lru
Метрики: hit rate, задержка; кеш не должен быть единственным источником правды
Что могут спросить следом
- Как инвалидировать списки товаров по категории?
- Что будет, если Redis упадёт?
- Когда хватит кеша в памяти процесса?
Разбор
Сначала посмотрю, какие запросы реально горячие и как часто меняются данные: каталог читают в сотни раз чаще, чем правят, это хороший кандидат.
Беру cache-aside в Redis: при промахе читаю из базы, кладу в кеш с TTL в несколько минут. Ключи именую по схеме, например product:42. При изменении товара удаляю его ключ и связанные списки. Для списков удобно хранить номер версии категории в имени ключа: при изменении увеличиваю версию, а старые ключи сами истекут по TTL.
Учитываю лавину: для популярных ключей пересчитывает один запрос под блокировкой SET NX, внутри процесса одинаковые запросы объединяю в один промис, к TTL добавляю разброс. Redis настраиваю с лимитом памяти и политикой allkeys-lru.
Наконец, кеш не должен ломать сервис: если Redis недоступен, иду в базу с коротким таймаутом. И слежу за hit rate, чтобы понимать, что кеш вообще помогает.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.