TTL не настраивают «на глаз»: без метрик трафик и кэш начинают спорить друг с другом

TTL не настраивают «на глаз»: без метрик трафик и кэш начинают спорить друг с другом

Если смотреть только на средний hit ratio, легко пропустить главную проблему: часть запросов может жить на коротком TTL и создавать лишнюю нагрузку, а часть — слишком долго удерживать устаревший контент. В итоге CDN формально работает, но origin получает лишние обращения, а пользователи — лишние задержки.

Разбирайте не общий трафик, а его профиль:
— долю повторных запросов по URL и шаблонам;
— время жизни объектов по типам контента;
— частоту инвалидаций и обновлений на origin;
— всплески miss-ов после деплоя или публикации.

Для часто меняющихся страниц короткий TTL оправдан, если обновления предсказуемы и кэш легко прогревается. Для статических ассетов лучше длинный TTL с версионированием имени файла. Это снижает число revalidate-запросов и убирает зависимость от лишних походов к источнику. Плохая практика — одинаковый TTL для HTML, API и медиа: у этих классов разная цена устаревания и разная нагрузка на backend. 🔧

Смотрите не только на кэш, но и на распределение по статусам, объёму объектов и времени ответа origin. Если после увеличения TTL растёт доля stale-данных, стратегия неверна; если после уменьшения TTL падает hit ratio и растёт TTFB, вы платите за избыточную свежесть. Стабильность инфраструктуры — залог масштабируемости.