TTL нельзя выбирать «на глаз»: сначала смотрим на профиль трафика и частоту изменений

TTL нельзя выбирать «на глаз»: сначала смотрим на профиль трафика и частоту изменений

Если кэш обновляется редко, а контент живёт долго, короткий TTL только увеличивает нагрузку на origin без заметной пользы. Если же на сайте часто меняются цены, остатки, персонализация или API-ответы, слишком длинный TTL быстро превращает CDN в источник устаревших данных.

Полезно разложить трафик по типам:
— статические ассеты: высокий TTL, агрессивный кэш;
— HTML-страницы: умеренный TTL и аккуратная инвалидация;
— API и динамика: либо минимальный TTL, либо bypass;
— редкие, но тяжёлые объекты: отдельные правила кэширования.
Смотрите не только на объём запросов, но и на churn: сколько объектов реально меняется за интервал. Это лучший индикатор того, где TTL надо сокращать, а где — наоборот увеличивать.

В метриках важны три сигнала: hit ratio, доля revalidate-запросов и время до устаревания данных на клиенте. Высокий hit ratio сам по себе не гарантирует качество: если пользователи получают старые ответы, бизнес-ошибка дороже экономии на origin.

Базовая стратегия проста: повышайте TTL там, где контент предсказуем, и снижайте там, где цена устаревания выше цены лишнего запроса. Оптимизация — это непрерывный процесс, а не разовая настройка.