ISR и слои CDN: stale-while-revalidate на origin, кеши по подам и порядок purge

ISR — это stale-while-revalidate на origin

revalidate: 60 не значит «регенерировать каждые 60 секунд» и не значит «пользователи ждут свежий HTML». Это stale-while-revalidate (SWR — «отдай устаревшее, ревалидируй в фоне»), реализованный на origin: каждая закешированная запись несёт таймстемп, и первый запрос после истечения окна немедленно получает устаревшую страницу — единицы миллисекунд из кеша, — пока в фоне стартует ровно одна регенерация. Когда рендер завершается, новая запись подменяется атомарно: ни один запрос не видит полузаписанную страницу. Если регенерация падает — подмена просто не происходит: последняя удачная страница продолжает раздаваться, а следующий запрос после окна повторит попытку. Арифметика раздачи и делает ISR привлекательным: попадание в кеш — 1–5 мс IO, полная регенерация — сколько стоит рендер страницы, обычно 100–800 мс выборки данных и работы RSC, — и при ISR её никто не ждёт, кроме самой регенерации.

// app/pricing/page.tsx — по времени: максимум одна регенерация на окно в 60 с
export const revalidate = 60;

// или на каждый fetch, с тегами для on-demand-инвалидации:
const res = await fetch('https://cms.example.com/prices', {
  next: { revalidate: 60, tags: ['pricing'] },
});

// app/api/cms-webhook/route.ts — on-demand: инвалидировать сейчас, а не по таймеру
import { revalidateTag } from 'next/cache';
export async function POST() {
  revalidateTag('pricing'); // помечает записи устаревшими — ТОЛЬКО В ЭТОМ ПРОЦЕССЕ
  return Response.json({ ok: true });
}

Больше одного пода: кеш обязан быть общим

Всё сказанное выше верно на процесс. Дефолтное хранилище ISR — файловый кеш в .next/cache плюс in-memory LRU — локально для пода по обоим пунктам. Один под — одна истина. Три пода — три истины: каждый регенерирует по собственному расписанию, и страницы с временны́м revalidate расходятся на ширину окна — обычно терпимо. Нетерпимо другое — on-demand-ревалидация: revalidatePath и revalidateTag мутируют локальное хранилище того пода, на котором выполнились. Вебхук приземляется на под B, под B регенерирует, поды A и C об этом не услышат никогда — и round-robin-балансировщик превращает это во флип-флоп из вступления: свежее и устаревшее чередуются на каждый запрос. Без временно́го фолбэка устаревшие поды не сойдутся вовсе.

Два продакшен-уровневых лечения. Структурное: заменить хранилище на общий cacheHandler — next.config.js принимает cacheHandler: require.resolve('./cache-handler.mjs') плюс cacheMaxMemorySize: 0, отключающий per-pod LRU, а ваш обработчик реализует get/set/revalidateTag поверх Redis или другого общего стора. Истина снова одна; цена — ~1–3 мс RTT до Redis на каждом попадании ISR вместо субмиллисекундного локального диска — стоимость консистентности. Альтернатива оставляет локальные кеши, но разносит инвалидацию веером: вебхук публикует в Redis pub/sub (publish/subscribe — модель «публикатор/подписчик»), каждый под подписан и вызывает revalidateTag локально. Веер сохраняет скорость локального диска, но возвращает задачу распределённых систем: под, который перезапускался в момент публикации, её пропустил — и ничто его не примирит. Проще говоря: общий стор гарантирует корректность по конструкции, веер — даёт скорость ценой пробела, который нужно мониторить. Общий стор — скучный правильный дефолт; веер — оптимизация, которую берут вместе с мониторингом.

Слой CDN сверху — и порядок purge

Перед подами стоит CDN, и ISR-страницы сами ему представляются: роут с revalidate: 300 уезжает с Cache-Control: s-maxage=300, stale-while-revalidate — CDN может кешировать его пять минут и отдавать устаревшее, пока перезапрашивает. Здоровый контентный сайт держит 80–98% попаданий в CDN, то есть поды видят только ручеёк промахов; CDN танцует тот же stale-while-revalidate этажом выше — против вашего origin вместо вашей функции рендера. Два кеша, один протокол, стопкой.

У стопки кешей есть теорема порядка, и её нарушение — второй классический инцидент: сначала регенерировать origin, потом чистить CDN. Запустите наоборот — и пройдитесь по таймлайну: purge завершился, CDN пуст, каждый запрос страницы — промах в ваш origin — лавина промахов, — а origin, который ещё не регенерировал, послушно отдаёт старую страницу по семантике SWR. CDN снова кеширует эту старую страницу, проштампованную свежим s-maxage=300, и ваш «срочный фикс» закреплён ещё на целое окно — вы почистили кеш, и устаревший контент вернулся как ни в чём не бывало. Правильная последовательность: дёрнуть revalidateTag/revalidatePath на origin (дойдя до каждого пода, см. предыдущий раздел), убедиться, что origin отдаёт свежее, и только потом чистить CDN — чтобы промахи вытянули новую страницу. Лавина всё равно случится — столько стоит purge, — но вытянет правильные байты.