Многоуровневый кеш и Cache-Control

CDN стоит перед origin, но alarm origin по-прежнему срабатывает при каждом деплое. Новые пользователи промахиваются по кешу, каждый edge POP одновременно запрашивает origin — и вдруг 200 edge-серверов генерируют 200 параллельных запросов к origin для одного и того же некешированного URL. Это не баг — это отсутствие архитектурного слоя: origin shield.

Четырёхуровневая иерархия кешей

Когда браузер делает запрос, четыре кеша могут ответить до origin:

1. Кеш памяти браузера (~субмс, живёт в рамках вкладки)
2. Дисковый кеш браузера (~10 мс, сохраняется между вкладками)
3. Кеш CDN edge POP (~20–50 мс по сети от пользователя)
4. CDN origin shield / региональный кеш (~50–100 мс)

Только если все четыре промахиваются, отвечает origin (~100–300 мс в зависимости от географии). Каждый слой подчиняется одним и тем же директивам Cache-Control, но применяет их независимо.

Директивы Cache-Control

Заголовок ответа Cache-Control сообщает каждому кеширующему слою, что делать с ответом:

Важнейшее правило: без Cache-Control: public (или s-maxage) CDN проксирует насквозь — кеширования не происходит. Заголовки ответа origin управляют кешируемостью; CDN не может кешировать то, что origin не разрешает.

Архитектура origin shield

В каждом регионе CDN может быть десятки edge POP. Без shield промах кеша для популярного URL во всех 200 POP генерирует 200 одновременных запросов к origin — thundering herd (эффект гремящего стада).

Origin shield (называемый «Tiered Cache» у Cloudflare, «Origin Shield» у Fastly — одна фича) — это региональный промежуточный кеш между edge POP и origin. Все edge POP в регионе направляют промахи через один shield-узел. Shield поддерживает бо́льший кеш и обычно поглощает 90%+ промахов без обращения к origin.

Сценарий для «холодного» URL:

1. 200 edge POP промахиваются одновременно.
2. Все 200 пересылают запрос к региональному shield.
3. Shield отправляет один запрос к origin; остальные 199 ставятся в очередь.
4. Origin отвечает один раз; shield распространяет ответ на все 199 ожидающих edge.
5. Origin увидел 1 запрос вместо 200.

Версионирование статических ассетов: избавиться от инвалидации

Умнейший трюк с кешем: включить content hash в имя файла (например, app.f3a2b8c.js). Задать max-age=31536000, immutable (1 год). Когда файл меняется — меняется хеш, меняется URL — в кеше нет записи для нового URL, и он автоматически загружается свежим. Purge не нужен. Это делают автоматически: Webpack, Vite, esbuild, Astro.

Паттерны инвалидации кеша (когда всё-таки нужны)

1. Истечение TTL — ждать, пока истечёт max-age. Дёшево, без API-вызовов, но медленно при срочных исправлениях.
2. Явный purge — API-вызов CDN: POST /purge {"url": "/api/products"}. Быстро, но медленно при purge тысяч URL на деплое.
3. Cache tags — теговать ответы на origin (Cache-Tag: article-1001), чистить по тегу (POST /purge {"tag": "article-1001"}). Максимальная гибкость; требует enterprise-тира CDN (Fastly, Cloudflare Enterprise).

Условные запросы и 304 Not Modified

После истечения локального кеша браузер ревалидирует с If-None-Match: <etag>. Если ответ не изменился, CDN (или origin) возвращает 304 Not Modified — пустое тело, экономия трафика. CDN прозрачно обрабатывает ETag для кешируемых ответов, пересылая к origin только при реально изменившемся ETag.