Кэши

Коротко: Промежуточное хранилище, сохраняющее уже полученные данные для более быстрого повторного доступа.

Подробнее: Кэши существуют на многих уровнях — в браузере (HTML/CSS/JS/изображения), на DNS-резолверах (ответы до истечения TTL), в CDN или в подключении приложения к базе данных. Цель всегда одна: реже обращаться к более медленным первоисточникам (сеть, база данных).

Подробности

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

• Кэш браузера: хранит статические ресурсы (изображения, CSS, JS) локально на устройстве пользователя — самый быстрый слой, но отдельный для каждого устройства.
• Кэш CDN: глобально распределённая сеть серверов, держащая содержимое географически близко к пользователю — например, edge-сеть Vercel автоматически кэширует статические страницы Emzett.
• Кэш DNS: резолверы запоминают ответы до истечения TTL, чтобы не проходить всю цепочку DNS заново при каждом запросе.
• Кэш приложения/базы данных: например, кэши Redis для дорогих запросов к базе данных.

Каждый из этих кэшей может выдавать устаревшие («stale») данные, если первоисточник меняется до обновления кэша, — поэтому фундаментальная проблема кэширования не в самом кэшировании, а в своевременной и правильной инвалидации. Для этого есть две базовые стратегии: истечение по времени (кэш автоматически отбрасывает запись после фиксированного TTL, независимо от того, изменились ли данные на самом деле) и явная инвалидация (приложение активно сообщает кэшу «эта запись теперь недействительна», например сразу после обновления базы данных).

Согласованность кэша как настоящая проблема

При нескольких слоях кэша одновременно (браузер, CDN, приложение) один и тот же запрос может давать ответы разной актуальности в зависимости от слоя — пользователь, например, всё ещё видит в кэше браузера старую цену товара, а CDN уже давно отдаёт новую. Именно это регулируют заголовки HTTP, такие как Cache-Control и ETag:

Cache-Control: max-age=3600, must-revalidate
ETag: "a1b2c3d4"

max-age указывает, как долго клиент может использовать ответ без нового запроса; must-revalidate затем принуждает к проверке на сервере (вместо того чтобы просто продолжать использовать устаревшую версию); ETag — отпечаток содержимого, позволяющий серверу при такой проверке эффективно выяснить, изменилось ли что-то на самом деле, не передавая заново весь ответ (ответ 304 Not Modified, если нет).

Областью, которую в Emzett намеренно НЕ кэшируют, является, например, состояние корзины — здесь даже кэш со временем жизни в несколько секунд был бы реальным риском показать неверные остатки.

См. также: Кэширование (caching), TTL