Кеширование
Уровни кэша: поставь кэш туда, где он окупается
Читать про лестницу задержек — не то же самое, что решить, где место кэшу под реальным трафиком. Построй небольшой путь чтения через несколько слоёв, измерь каждый и докажи числами, какой cache окупается, а какой — лишь задержка и риск.
Преврати ментальную модель юнита в цикл измерений: заинструментируй стек слоёв, измерь задержку origin и пер-слойный hit ratio, поставь cache туда, где сошлись три ворот (медленный origin, высокий hit ratio, терпимость к устареванию), и подтверди числами до/после — затем намеренно внеси и обнаружь баг wrong-layer или double-caching.
Возьми небольшой read-heavy сервис как минимум с двумя разными эндпоинтами — одним дорогим (join по нескольким таблицам или агрегат) и одним дешёвым (тёплый primary-key lookup) — и реши с измерениями, где (если вообще) каждый из них кэшировать по стеку слоёв: app cache (Redis), reverse proxy и CDN. Докажи каждое решение о размещении числами до/после, затем почини один внесённый сбой.
- Таблица до/после на эндпоинт: задержка origin, кэшированная средняя задержка, p99, пер-слойный hit ratio и нагрузка на БД — измеренные под идентичной нагрузкой, а не оценённые.
- Доказательство, что кэширование быстрого PK эндпоинта в Redis подняло его задержку (wrong-layer регрессия), с числами и однострочным объяснением, привязывающим это к лестнице задержек.
- Пер-слойный трейс (X-Cache / CF-Cache-Status / Age) для одного запроса к медленному эндпоинту, показывающий путь hit/miss вниз по стеку и какой слой его отдал.
- Внесённый сбой воспроизведён с доказательством (устаревшее чтение после записи или межпользовательская утечка), затем показан исправленным при том же тесте, с абзацем-описанием единого владельца и единого пути инвалидации, которые ты установил.
- Добавь stale-while-revalidate к заголовкам кэша медленного эндпоинта и покажи, что p99 падает, а ревалидации origin текут ручейком вместо всплеска на истечении TTL.
- Добавь однострановой runbook: триаж подозрения на устаревший кэш проходом по слоям (Age, CF-Cache-Status, X-Cache, логи proxy, hit/miss Redis, БД), с порядком и тем, что говорит каждый заголовок.
- Вычисли точку окупаемости hit ratio для медленного эндпоинта (ratio, ниже которого cache минусовой) и прогони микс нагрузки, уводящий реальный ratio ниже неё, демонстрируя, как cache становится чистым убытком.
- Добавь метрику, флагующую любой кэшируемый факт, хранимый на двух слоях с независимыми TTL (страж double-caching), и подключи её к дашборду.
Это цикл, который ты гоняешь, когда кто-то говорит «добавь кэш»: измерь реальную задержку origin, проверь три ворот (медленный origin, высокий hit ratio, терпимость к устареванию), поставь cache на слой, который позволяет волатильность данных, и докажи выигрыш числами до/после под идентичной нагрузкой. Кэширование быстрого PK lookup доказывает wrong-layer регрессию экспериментом; внесённый double-cache или межпользовательская утечка доказывает, почему один владелец и один путь инвалидации на факт — не обсуждаются. Сделав это один раз на игрушечном стеке, ты доводишь production-решение до мышечной памяти.