Кеширование
Кэширование, капстоун: спроектируй многоуровневую стратегию
Читать про скомпонованные кэши — не то же, что спроектировать кэш, держащийся под нагрузкой. Возьми реальный сервис со смесью статических, публичных и персональных ответов, спроектируй связную многоуровневую стратегию кэширования и докажи её: hit-rate вверх, нагрузка на origin вниз, нет устаревшего-после-правки, нет dogpile и нет утечки персональных данных — с доказательством на каждом шаге.
Преврати ментальную модель трека в готовый дизайн и рабочий срез: назначь каждому уровню данные, напиши политику Cache-Control по классу ресурса, добавь валидаторы и защиту от stampede, встрой инвалидацию в write-path и проверь, что весь стек компонуется под нагрузкой.
Спроектируй и частично реализуй многоуровневую стратегию кэширования (edge CDN + reverse proxy + application-кэш + БД) для реального сервиса минимум с тремя классами ресурсов — хэшированный статический ассет, публичное кэшируемое чтение и персональный аутентифицированный ответ — затем докажи, что стратегия держится под нагрузкой, с измеренными числами до/после.
- Таблица до/после: hit-rate кэша (по уровням), частота запросов к origin и p99-задержка — измеренные под той же нагрузкой, не оценочные — показывающие снижение нагрузки на origin и рост hit-rate.
- Продемонстрированный тест правка-до-видимости: измени товар и покажи, что новое значение появляется в браузере в задокументированном окне инвалидации, с порядком распространения (Redis → proxy → CDN), подтверждённым в логах или ответах purge.
- Продемонстрированный тест без-утечки: подтверди, что персональный аутентифицированный ответ никогда не сохраняется разделяемым кэшем (например, ответ несёт private/no-store, а CDN/proxy сообщает bypass/MISS для него).
- Продемонстрированный тест без-dogpile: истеки горячий ключ под параллельной нагрузкой и покажи, что origin видит один пересчёт (single-flight) или ноль блокирующихся читателей (SWR), а не N одновременных запросов.
- Одностраничный разбор карты владения и таблицы политики по-ресурсно, называющий, какой механизм защищает каждый failure mode (утечка, устаревшее-после-правки, dogpile, сбой) и почему.
- Добавь on-call runbook: как читать внезапный всплеск нагрузки на origin (у какого уровня упал hit-rate), как безопасно purge'нуть tag без полного flush и чеклист для выкатки изменения Cache-Control без утечки персональных данных.
- Добавь наблюдаемость кэша: счётчики hit/miss/bypass по уровням и панель возраст-против-свежести, чтобы с одного взгляда видеть, какой уровень обслужил каждый запрос.
- Добавь вероятностное раннее истечение (в стиле XFetch) на горячий ключ и сравни его профиль нагрузки на origin против комбинации single-flight + SWR под той же нагрузкой.
- Расширь инвалидацию до tag-based от края до края (surrogate-key на CDN и тегированные ключи Redis) и покажи, что один purge product:42 сбрасывает каждый зависимый кэшированный ответ — страницу, фрагмент и API-чтение — не трогая несвязанные ключи.
Это цикл, который ты будешь запускать, проектируя кэширование для любого реального сервиса: назначь владение до тюнинга, напиши политику Cache-Control по классу ресурса с разделением s-maxage/max-age и сокращением TTL наружу, сделай ревалидацию дешёвой через валидаторы, защити горячий ключ через single-flight плюс SWR, fail open через stale-if-error и встрой инвалидацию в write-path, чтобы изменение распространялось Redis → proxy → CDN по порядку. Затем докажи каждое свойство — hit-rate, без утечки, без устаревшего-после-правки, без dogpile, переживает сбой — измеренными числами под идентичной нагрузкой. Скомпоновать это раз на реальном сервисе и делает production-версию суждением, а не догадкой.