TTL (Time to Live)

TTL (Time to Live) is a value attached to a piece of stored data — most commonly a cache entry, but also DNS records, session tokens, and object storage lifecycle rules — specifying how long that data remains valid before it automatically expires and is either deleted or treated as stale and due for refresh. Why it matters for AI/SaaS builders: TTL is the primary lever for balancing freshness against performance/cost in nearly every caching decision an AI product makes. A TTL set too long risks serving stale data (a cached LLM response for a prompt whose underlying source document has since changed; a cached product price that's now wrong); a TTL set too short defeats the purpose of caching in the first place, forcing expensive recomputation or re-fetching far more often than necessary. Choosing the right TTL per data type is a genuinely important design decision, not an afterthought — and it's common (and reasonable) for different pieces of data in the same system to have very different TTLs based on how often they actually change. How it works: in Redis, TTL is set directly on a key (`SETEX key 3600 value` sets a value that expires in 3600 seconds, or `EXPIRE key 3600` on an existing key), after which Redis automatically removes the key without any explicit deletion call from the application. In HTTP caching and CDNs, TTL is communicated via `Cache-Control: max-age=3600` headers, telling browsers and CDN edge nodes how long they may serve a cached response before re-checking with the origin. In Next.js/Nuxt's ISR (Incremental Static Regeneration), a page's revalidation interval is effectively a TTL on a rendered page. Choosing TTL involves a real trade-off matrix: highly volatile data (a stock price, live inventory count) needs a very short TTL or event-driven invalidation instead; rarely-changing data (a glossary term definition, a completed AI generation) can safely use a very long TTL, sometimes measured in days. Worked example: an AI SaaS caches LLM-generated product descriptions with a 24-hour TTL — long enough to avoid re-generating (and re-paying for) the same description on every page view, short enough that a merchant's price or feature update is reflected in the AI-generated copy within a day without needing to build explicit cache-invalidation logic tied to every possible source-data change. This TTL-only approach is a deliberate simplicity trade-off: the team accepts up to 24 hours of staleness in exchange for never having to build and maintain event-driven cache invalidation across every code path that could change a product's underlying data — a reasonable bet for a feature where near-real-time accuracy isn't a hard requirement.