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

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

TTL в CDN — это не про экономию на DNS-запросах, а про управляемость изменений и нагрузку на origin. Если трафик ровный и контент меняется редко, TTL можно держать выше: меньше лишних резолвов, стабильнее поведение кэша. Если же у вас частые публикации, A/B-тесты или разные регионы с неодинаковой задержкой, слишком длинный TTL начинает мешать быстрее, чем помогает.

Смотрите не на среднюю посещаемость, а на распределение:
— всплески по времени суток;
— долю повторных визитов;
— процент промахов кэша по типам контента;
— сколько запросов уходит на origin после обновления объекта.

Если после правки контента вы видите долгий «хвост» старых ответов, TTL выбран слишком агрессивно. Если же резкие изменения вызывают лавину запросов к origin, TTL слишком короткий, а стратегия обновления кэша не выдерживает реальную нагрузку.

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

Оптимальная схема проста: измеряйте churn контента, смотрите cache hit ratio и время жизни объектов в кэше, затем подбирайте TTL под конкретный тип трафика. Стабильность инфраструктуры — залог масштабируемости.