Какие правила и триггеры используются для очистки кэша?

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

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

Как отвечать

Разведите два понятия: вытеснение и инвалидацию.

Вытеснение срабатывает, когда кэш переполнен, и не зависит от актуальности данных:

• LRU: выбрасывается то, к чему дольше всего не обращались;
• LFU: выбрасывается то, что читают реже всего;
• политика Redis: задаётся maxmemory-policy, по умолчанию стоит noeviction, то есть при заполнении памяти запись просто падает с ошибкой.

Инвалидация удаляет данные, потому что они устарели:

• TTL: запись живёт заданное время (EXPIRE в Redis, max-age в HTTP);
• по событию записи: при изменении данных приложение удаляет или обновляет ключ, иногда через событие в очереди;
• при деплое: статике дают хэш в имени файла, и новая версия получает новый адрес;
• ручной сброс: purge в CDN, команда администратора.

Для HTTP-кэша смотрите заголовки во вкладке Network: Cache-Control, ETag, ответ 304 Not Modified, пометки memory cache и disk cache. Помните, что no-cache не запрещает кэширование, а требует перепроверки у сервера; запрет это no-store.

Сценарии тестирования: изменить данные и сразу прочитать их из другого клиента; проверить поведение на границе TTL; убедиться, что личные данные не отдаются чужому пользователю из общего кэша (private, Vary); посмотреть нагрузку после массового сброса, когда все запросы разом уходят в базу.

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

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

Тестируют с галочкой Disable cache в DevTools или после жёсткой перезагрузки. Так баг с кэшем не воспроизвести, нужен сценарий обычного пользователя.

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