Кеширование
SWR: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту SWR — два окна, single-flight, stale-if-error, ревалидация на клиенте и опасность для auth.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает заголовок, который ты пишешь, или инцидент, который разбираешь — не директиву для заучивания, а компромисс «свежесть против задержки», который надо взвесить под реальным трафиком.
Цель
Убедись, что связываешь окно свежести, окно SWR, stale-if-error, single-flight и модель ревалидации на клиенте — и что знаешь единственное место, куда SWR ставить нельзя.
Викторина
Completed
Запрос приходит через 90 секунд после кэширования, с Cache-Control: max-age=60, stale-while-revalidate=300. Что получит пользователь и почему?
Heads-up Это поведение обычного max-age. Внутри окна SWR весь смысл в том, что пользователь НЕ блокируется — stale сейчас, обновление вне основного пути.
Heads-up Жёстким промахом это становится только после max-age + окно SWR (60+300=360с). Между 60с и 360с запись stale-но-отдаваемая.
Heads-up «While» означает, что обновление идёт, пока stale-ответ уже летит к пользователю. Синхронную ревалидацию SWR как раз и убирает.
Викторина
Completed
Почему один лишь max-age порождает пилу p99 на каждой границе TTL, и как stale-while-revalidate её сглаживает?
Heads-up max-age НЕ ревалидирует каждый запрос — он отдаёт из кэша до истечения. Пик возникает только на границе TTL, где перезаполнение блокирует живого пользователя. Именно это SWR выносит из пути запроса.
Heads-up Пик — не разброс origin, а синхронное перезаполнение, попавшее в запрос пользователя. SWR ничего не усредняет; он просто перестаёт заставлять человека ждать обновления.
Heads-up SWR не меняет max-age и стоимость промаха; он меняет, КТО платит за промах — фоновый fetch вместо живого пользователя. Round-trip к origin того же размера, просто никто на него не ждёт.
Викторина
Completed
Популярный ключ истекает при 10k rps, и edge запускает по одной фоновой ревалидации на каждый stale-hit. Что ломается и какой фикс?
Heads-up Пользователь не ждёт, но origin всё равно получает каждое обновление. Тысячи параллельных фоновых fetch расплавят origin так же, как стадо в основном пути.
Heads-up Удаление SWR возвращает пик синхронной ревалидации. Стадо — про коалесцирование параллельных обновлений, а не про окно устаревания.
Heads-up Пользователи получают stale-но-быстрые ответы, а не ошибки. Подъём max-age не останавливает параллельные фоновые fetch, штурмующие origin.
Викторина
Completed
Что stale-if-error добавляет поверх stale-while-revalidate, и почему пара — дефолт сеньора?
Heads-up Они независимы и зеркальны: stale-while-revalidate — для здорового origin, на который не хочется заставлять пользователей ждать; stale-if-error — для больного origin, где stale лучше 503.
Heads-up Ни одна из директив не блокирует пользователя. stale-if-error просто меняет поведение, когда фоновое обновление ПРОВАЛИВАЕТСЯ — продолжать отдавать stale вместо проброса ошибки.
Heads-up Он добавляет отдельное, обычно более длинное, окно только для отказов. Он не трогает окно SWR и обычное устаревание — это пол под авариями.
Викторина
Completed
Два компонента вызывают useSWR('/api/user') в одном тике рендера. Что делает клиентская библиотека SWR и что этим управляет?
Heads-up Дублирующие вызовы одного ключа коалесцируются на один in-flight запрос внутри dedupingInterval — в этом весь смысл клиентского слоя кэша.
Heads-up Нет ни блокировки, ни второго fetch. Оба компонента подписываются на единственный in-flight promise и получают тот же кэшированный результат.
Heads-up Вопрос про дедупликацию параллельных вызовов, а не про UI первой загрузки. SWR коалесцирует их в один запрос независимо от того, видел ли он ключ раньше.
Викторина
Completed
Для какого ответа stale-while-revalidate — неправильный инструмент и почему?
Heads-up Это классическое попадание SWR — ограниченное устаревание безвредно, а реальная цена — пила p99. Здесь SWR ровно то, что нужно.
Heads-up Слегка устаревшая аналитика — это нормально; SWR отдаёт её мгновенно и тихо обновляет в фоне. В ней нет угрозы корректности или безопасности.
Heads-up Почти статичный контент прекрасно терпит устаревание; SWR идеален. Неправильная цель — данные, где stale равно баг безопасности или корректности, как auth.
Итог
Сквозная линия — один контракт: верни то, что есть сейчас, подтяни то, что верно, следующим, и никогда не заставляй человека ждать обновления. max-age задаёт свежесть, окно SWR убивает пилу синхронной ревалидации, stale-if-error превращает аварию в degraded-but-up, single-flight плюс джиттер останавливают стадо фоновых обновлений, а клиентские библиотеки воспроизводят ту же модель через dedupingInterval и ревалидацию на focus/reconnect. Единственная жёсткая граница: никогда не применяй SWR к auth, правам и всему, где устаревшие данные — баг безопасности.