Кэшируйте данные, которые дорого производить, часто читаются и редко меняются — именно здесь кэширование окупается. TTL (время жизни) — это компромисс между свежестью (насколько актуальны данные) и допустимостью устаревания (насколько неверные данные могут быть и как долго).
Хороший кандидат на кэширование набирает высокие баллы по всем трём критериям:
Не кэшируйте дешево вычисляемые, часто пишущиеся или секретные данные, специфичные для пользователя, требующие абсолютной свежести (например, остаток счета в момент транзакции).
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
Для корректности данных, меняющихся непредсказуемо, комбинируйте TTL с явной инвалидацией: write-through или delete-on-write, чтобы кэш очищался в тот момент, когда меняется источник, вместо ожидания истечения.
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
Следите за коэффициентом попадания в кэш для настройки TTL: низкий коэффициент означает, что вы почти не кэшируете; высокий коэффициент с жалобами на устаревание означает, что TTL слишком длинный.
Правильный выбор того, что кэшировать, и установка правильного TTL — это ядро эффективного кэширования. Кэширование неправильных данных добавляет сложность без выигрыша; слишком длинный TTL приводит к устаревшим данным; слишком короткий означает потерю преимуществ. Использование допустимости устаревания для выбора TTL, добавление явной инвалидации для корректности и мониторинг коэффициента попадания дают вам принципиальный, измеримый способ кэширования.