Кэширование на практике: что, где и когда

Сводный урок: как выбрать стратегию кэширования для конкретного сценария, какие метрики мониторить и типичные архитектурные решения для проектов разного масштаба.

Почему это важно: Теория кэширования бесполезна без практического контекста. Этот урок даёт фреймворк для принятия решений: кэшировать или нет, какой TTL выбрать, какой уровень использовать.

Главная идея

Решение о кэшировании определяется соотношением read/write: если данные читаются в 10 раз чаще, чем обновляются — кэш даст огромный выигрыш. Выбор уровня (HTTP, app, Redis) зависит от требований к свежести и инфраструктуры.

Как это выглядит на практике

Профилирование: определяем топ-10 самых тяжёлых и частых эндпоинтов
Анализ: для каждого считаем read/write ratio и требования к свежести
Решение: выбираем уровень кэша (HTTP, in-process, Redis) и стратегию
Реализация: добавляем кэш с метриками (hit rate, latency)
Мониторинг: отслеживаем hit rate, memory usage, eviction rate
Оптимизация: корректируем TTL и стратегию на основе метрик

Примеры кода

Многоуровневое кэширование

class ProductService
  # Уровень 1: in-process cache (без сети)
  MEMORY_CACHE = ActiveSupport::Cache::MemoryStore.new(size: 64.megabytes)

  # Уровень 2: Redis (общий для всех процессов)
  REDIS_CACHE = ActiveSupport::Cache::RedisCacheStore.new(
    url: ENV['REDIS_URL'],
    expires_in: 10.minutes
  )

  def popular_products
    # Сначала проверяем локальный кэш (0 мс)
    MEMORY_CACHE.fetch('popular', expires_in: 30.seconds) do
      # Затем Redis (< 1 мс)
      REDIS_CACHE.fetch('popular_products', expires_in: 5.minutes) do
        # Только потом БД (10-100 мс)
        Product.popular.limit(20).to_a
      end
    end
  end
end

Чеклист: кэшировать или нет?

# Кэшировать, когда:
- read/write ratio > 10:1
- запрос > 50 мс
- данные одинаковы для многих пользователей
- допустимо устаревание на N секунд

# НЕ кэшировать:
- персональные данные с частым обновлением (баланс, корзина)
- write-heavy данные (логи, аналитика)
- данные, которые всегда должны быть актуальны (статус оплаты)
- когда объём данных не помещается в RAM

# Выбор уровня:
HTTP Cache-Control:  статика, публичные данные, CDN
In-process (Memory): горячие данные, конфиг, справочники
Redis/Memcached:     общий кэш для всех серверов/процессов
DB query cache:      часто повторяющиеся сложные запросы

Что происходит под капотом

In-process кэш (MemoryStore) — самый быстрый (0 мс), но не shared между процессами/серверами
Redis/Memcached — shared кэш, < 1 мс, но требует сети и сериализации
Метрики для мониторинга: hit rate, miss rate, eviction rate, memory usage, latency p99
Cache warming (прогрев) — заполнение кэша данными до того, как придут реальные запросы
Graceful degradation: при падении Redis приложение должно продолжать работать (только медленнее)

Типичные ошибки и заблуждения

«Кэш нужно добавлять сразу» — преждевременная оптимизация; сначала профилируйте и найдите реальные узкие места
«Один уровень кэша достаточен» — для высоконагруженных систем многоуровневый кэш даёт лучший результат
«Redis может заменить БД» — Redis — кэш, не primary storage, данные могут быть потеряны

Ключевые выводы

Read/write ratio определяет эффективность кэша: чем чаще чтение относительно записи, тем полезнее кэш
Многоуровневый кэш: Memory → Redis → DB — каждый уровень ловит промахи предыдущего
Мониторинг обязателен: hit rate, eviction rate, memory usage — без метрик кэш работает вслепую

Термины урока

{:term=>"Read/write ratio", :definition=>"Соотношение операций чтения к записи — определяет потенциальную эффективность кэширования"}

{:term=>"Cache warming", :definition=>"Предварительное заполнение кэша данными при старте приложения для предотвращения cold start"}

{:term=>"Eviction", :definition=>"Автоматическое удаление записей из кэша при нехватке памяти (по LRU, LFU или другой политике)"}

Связь с работой backend-разработчика

Кэширование — инструмент с высокой отдачей, но не серебряная пуля. Начинайте с профилирования, кэшируйте самые горячие endpoint'ы, мониторьте hit rate. Если он ниже 50% — пересмотрите стратегию или откажитесь от кэша для этого сценария.

Мини-разбор реальной ситуации

SaaS-платформа с 500 RPS. Профилирование показало: 60% запросов — чтение каталога (одинакового для всех), 25% — персональные дашборды. Решение: каталог → HTTP-кэш с Cache-Control: public, max-age=60 (нагрузка упала на 60%), дашборды → Redis-кэш с TTL 30 секунд + инвалидация по событию (нагрузка на БД снизилась на 40%).

Что запомнить

Профилируйте перед кэшированием — найдите реальные узкие места
Read/write ratio > 10:1 — идеальный кандидат для кэша
Мониторьте hit rate: > 90% — отлично, < 50% — пересмотрите стратегию

Итог

Кэширование — мощный инструмент ускорения бэкенда при правильном применении. Профилируйте, выбирайте подходящий уровень и стратегию, мониторьте метрики. Кэш без мониторинга — бомба замедленного действия.