Как обновляется кэш при изменении данных на сервере

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

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

Как отвечать

Разложите ответ по слоям:

• HTTP-кэш браузера и CDN: управляется заголовками. Cache-Control: max-age=60 минуту отдаёт копию без запроса, no-cache хранит копию, но перепроверяет её каждый раз, а ETag с If-None-Match позволяют серверу ответить 304 без тела;
• статика: хэш в имени файла плюс max-age=31536000, immutable, сам HTML с no-cache. Новый билд даёт новые имена, и старые файлы просто перестают запрашиваться;
• Service Worker: свой Cache API и свои стратегии, обновлением управляет ваш код;
• кэш данных в приложении: TanStack Query, RTK Query, SWR, Apollo.

Как такой кэш узнаёт об изменениях:

• своя мутация: после успешного запроса вызвать queryClient.invalidateQueries({ queryKey: ['users'] }) или связать запросы тегами через providesTags и invalidatesTags в RTK Query;
• оптимистичное обновление: поменять кэш до ответа сервера и откатить при ошибке;
• чужие изменения: сервер сообщает о них через WebSocket или SSE, клиент инвалидирует ключ. Варианты проще: refetchInterval или перезапрос при возврате на вкладку, в TanStack Query он включён по умолчанию;
• время свежести: staleTime по умолчанию равен нулю, данные сразу считаются устаревшими и перезапрашиваются при следующем монтировании.

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

Путают no-cache и no-store. Первый разрешает хранить копию с обязательной проверкой, второй запрещает хранение вообще.

Кладут ответы API в localStorage без срока жизни и версии. После релиза с новой структурой данных у части пользователей ломается интерфейс, и помогает только очистка хранилища.

Делают оптимистичное обновление, не отменив текущие запросы через cancelQueries. Старый ответ приходит позже и затирает новое значение.