Stale-while-revalidate и CDN request coalescing

Lock-based кеш даёт 10 000 ожидающим запросам одно из двух: перестроенное значение (после 400 мс ожидания) или fallback. Stale-while-revalidate немедленно даёт всем 10 000 ожидающим старое значение — и ставит в очередь ровно один фоновый refresh. Ноль ожидания, ноль спайка БД.

RFC 5861: стандарт

RFC 5861 (2010) определяет два расширения Cache-Control:

• stale-while-revalidate=N — отдавать устаревший (истёкший) кешированный ответ до N секунд, инициируя фоновую ревалидацию. Пользователь видит ответ без ожидания.
• stale-if-error=N — отдавать устаревший кешированный ответ до N секунд, если ревалидация падает (5xx, таймаут). Держит сайт доступным при сбоях origin.

Пример заголовка:

Cache-Control: max-age=60, stale-while-revalidate=30, stale-if-error=3600

Это означает: свежий 60 с, отдавать stale ещё 30 с при фоновом обновлении, отдавать stale до 1 часа при ошибке origin.

Что происходит на истечении TTL

С включённым SWR на кеше (CDN или application-level):

1. T=60.0 с — TTL срабатывает. Ключ теперь «устаревший, но в рамках stale-while-revalidate».
2. Запросы 1–N приходят в T=60.001 с.
3. Все N запросов немедленно получают stale-значение. Без ожидания.
4. В очередь ставится ровно один фоновый refresh (кеш выбирает первый запрос или использует отдельный background task).
5. T=60.4 с — фоновый refresh завершается. Новое значение сохранено.
6. Будущие запросы получают свежее значение.

Нагрузка на БД на границе: 1 запрос, не N.

Компромисс: ограниченный staleness

SWR явно принимает, что читатели будут видеть устаревшие данные до stale-while-revalidate длительности после истечения max-age. Это нормально для:

• Контент-страниц, новостных лент, product listings
• Баннеров главной страницы, навигационных меню
• Любых данных, где лаг 30–300 с незаметен пользователям

Это неправильно для:

• Баланса счёта, счётчиков голосов, всего, что влияет на бизнес-решения в реальном времени
• Всего, где два пользователя должны видеть согласованное состояние одновременно

CDN-уровень: request coalescing

CDN расширяют SWR с request coalescing (Cloudflare) или request collapsing (Fastly). Когда cache miss приходит на edge:

1. Edge входит в состояние «stitching» — он выпустил один upstream fetch и ждёт ответа.
2. Любые дополнительные запросы на тот же путь в состоянии «stitching» не генерируют дополнительных upstream fetch.
3. Все ожидающие запросы получают ответ одновременно, когда единственный upstream fetch завершается.

Вирусный контент-event с 10 миллионами зрителей, хитящими один URL, производит один origin-fetch, не 10 миллионов. Cloudflare и Fastly публикуют, что request coalescing превращает sudden-traffic инциденты в low-impact события на origin.

Framework-уровень: Next.js ISR

Next.js Incremental Static Regeneration (ISR) — SWR на уровне фреймворка. Страница с revalidate: 60 обслуживается из кеша 60 секунд; первый запрос после revalidate-окна триггерит фоновую регенерацию, пока stale-страница продолжает обслуживать. Форма идентична RFC 5861 — фреймворк просто реализует это без HTTP Cache-Control заголовков.