Что такое кэширование

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

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

На интервью удобно ответить так:

Кэширование хранит копию результата ближе к клиенту или сервису, чтобы быстрее обслуживать повторные запросы. Но вместе с кэшем всегда нужна стратегия актуальности: TTL, ревалидация, инвалидация или версионирование. Иначе мы ускорим не правильные данные, а старые данные.

Во frontend вы сталкиваетесь не с одним кэшем, а с несколькими уровнями. Браузер может кэшировать HTTP-ответы и статические файлы. CDN может хранить копии ассетов ближе к пользователю. Клиентское приложение может держать результаты запросов в памяти через библиотеку данных. Сервер может хранить результат тяжелого запроса в Redis.

Практический смысл в том, что каждый уровень ломается по-своему. У браузерного кэша важны заголовки. У CDN важны ключ кэша и приватность данных. У кэша запросов в UI важна инвалидация после мутаций. У storage в браузере важны срок жизни, размер, безопасность и ручная очистка.

Хорошая стратегия зависит не от желания "сделать быстрее", а от цены устаревших данных. Если файл имеет хэш в имени, его можно хранить долго. Если данные меняются редко, подойдет TTL и ревалидация. Если пользователь только что изменил сущность, нужно обновить или сбросить связанные кэши.

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

Cache-Control: public, max-age=31536000, immutable

Это безопасно только если URL меняется при изменении файла, например app.8f3a1.js. Если отдавать долгий TTL для обычного app.js, часть пользователей после релиза может продолжать запускать старый код. Из-за этого появляются странные ошибки. Новая HTML-страница ожидает один API-контракт, а старый JavaScript работает с другим.

Для данных, которые могут измениться, часто полезна ревалидация. Сервер отдает ETag, клиент при следующем запросе отправляет условный запрос, а сервер может вернуть 304 Not Modified. Так вы экономите трафик, но все еще проверяете свежесть.

Кэш запросов в UI нужен не только для скорости. Он также убирает лишние спиннеры, дедуплицирует одинаковые запросы и помогает не дергать API при каждом переходе между вкладками. Но после изменения данных его нужно синхронизировать.

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

async function saveProfile(values) {
  await api.patch("/profile", values);
  // Плохо: кэш запроса /profile остался старым.
  closeModal();
}

Безопаснее после успешной мутации обновить кэш или инвалидировать связанный запрос.

async function saveProfile(values) {
  const updatedProfile = await api.patch("/profile", values);
  queryClient.setQueryData(["profile"], updatedProfile);
  closeModal();
}

Если ответ мутации не содержит полную сущность, безопаснее инвалидировать запрос и показать состояние обновления, а не подставлять неполные данные в UI.

async function saveProfile(values) {
  await api.patch("/profile", values);
  await queryClient.invalidateQueries({ queryKey: ["profile"] });
  closeModal();
}

Если вы используете другую библиотеку или свой слой данных, идея та же. После записи UI не должен продолжать показывать старую копию как актуальную.

Первый риск: stale data. Он особенно заметен в корзине, правах доступа, статусах заказа, ценах и формах. Пользователь может нажать кнопку, которой уже не должно быть, отправить старое значение или увидеть неверный результат операции.

Второй риск: приватность. Ответ, который зависит от cookie, токена или роли пользователя, нельзя бездумно отдавать в общий кэш. Для таких данных нужны осторожные заголовки и понимание, где именно хранится копия.

Третий риск: лишняя память и лишние запросы. Если складывать в память все ответы без лимитов и очистки, приложение может деградировать по производительности. Если не дедуплицировать одинаковые запросы, несколько компонентов могут одновременно дергать один API и перетирать состояние ответами в разном порядке.

Сильный ответ удобно строить в три шага.

1. Дайте определение: кэш хранит копию результата для быстрого повторного доступа.
2. Назовите уровни: браузер, CDN, клиентское приложение, серверный кэш.
3. Объясните цену: нужна инвалидация, ревалидация или TTL, иначе будут старые данные и баги в UI.

Пример короткого ответа:

Кэширование сохраняет копию данных или ресурсов в более быстром месте, чтобы повторный запрос не шел по полному пути. Например, браузер может кэшировать JS и CSS, CDN может отдавать картинки ближе к пользователю, а клиентское приложение может держать результаты API-запросов в памяти. Но у кэша должна быть стратегия обновления: TTL, ETag, версия файла или инвалидация после мутации. Без этого можно ускорить загрузку, но показать пользователю устаревшие или даже чужие данные.