TTL (время жизни)

TTL (Time to Live, время жизни) — это значение, присвоенное хранимому фрагменту данных — чаще всего записи в кэше, но также записям DNS, токенам сессий и правилам жизненного цикла объектного хранилища, — определяющее, как долго эти данные остаются действительными, прежде чем автоматически истекут и будут либо удалены, либо помечены как устаревшие и подлежащие обновлению. Почему это важно для разработчиков AI/SaaS-продуктов: TTL — это основной рычаг для баланса между актуальностью данных и производительностью/стоимостью практически в любом решении о кэшировании в AI-продукте. Слишком длинный TTL рискует отдавать устаревшие данные (закэшированный ответ LLM для промпта, чей исходный документ с тех пор изменился; закэшированная цена товара, которая теперь неверна); слишком короткий TTL сводит на нет саму суть кэширования, вынуждая гораздо чаще, чем нужно, выполнять дорогостоящий пересчёт или повторную загрузку. Выбор правильного TTL для каждого типа данных — это по-настоящему важное проектное решение, а не второстепенная деталь, и вполне нормально (и разумно), когда разные фрагменты данных в одной и той же системе имеют совершенно разные значения TTL в зависимости от того, как часто они реально меняются. Как это работает: в Redis TTL задаётся непосредственно на ключе (`SETEX key 3600 value` устанавливает значение, срок действия которого истекает через 3600 секунд, либо `EXPIRE key 3600` — на уже существующем ключе), после чего Redis автоматически удаляет ключ без явного вызова удаления со стороны приложения. В HTTP-кэшировании и CDN TTL передаётся через заголовки `Cache-Control: max-age=3600`, сообщая браузерам и edge-узлам CDN, как долго они могут отдавать закэшированный ответ до повторной проверки с источником. В ISR (Incremental Static Regeneration) Next.js/Nuxt интервал ревалидации страницы фактически выступает TTL для отрендеренной страницы. Выбор TTL предполагает реальную матрицу компромиссов: сильно волатильные данные (цена акции, актуальный остаток на складе) требуют очень короткого TTL или инвалидации по событию вместо этого; редко меняющиеся данные (определение термина в глоссарии, завершённая генерация AI) могут безопасно использовать очень длинный TTL, иногда измеряемый днями. Практический пример: AI-SaaS кэширует сгенерированные LLM описания товаров с TTL в 24 часа — достаточно долго, чтобы не перегенерировать (и не переплачивать за) одно и то же описание при каждом просмотре страницы, и достаточно коротко, чтобы обновление цены или характеристики продавца отразилось в сгенерированном AI тексте в течение суток без необходимости строить явную логику инвалидации кэша, привязанную к каждому возможному изменению исходных данных. Такой подход «только TTL» — осознанный компромисс в пользу простоты: команда мирится с устареванием данных до 24 часов взамен на то, чтобы никогда не строить и не поддерживать событийную инвалидацию кэша по каждому пути кода, который мог бы изменить исходные данные продукта — разумная ставка для функции, где точность в реальном времени не является жёстким требованием.