What TTL is and where you meet it
TTL is an instruction saying when to treat this data as stale. It appears in three main contexts.
Caches (Redis, Memcached, a CDN) store query results or whole pages. The TTL decides how long a
cached response is served instead of going back to the database or the origin server.
DNS resolvers — at providers and in browsers — cache DNS records according to the TTL. A short
TTL means changes propagate quickly, at the cost of more queries to the DNS server.
The HTTP cache uses the Cache-Control: max-age=N and Expires headers to set a TTL for the
browser cache and any intermediate proxies.
Balancing speed against freshness
TTL is a compromise. A high TTL means fewer calls to the source and a faster site, but the data may
be out of date. A low TTL keeps data current but raises load on the backend.
Short TTL: freshness ↑, load ↑, latency ↑
Long TTL: performance ↑, freshness ↓
In e-commerce, different data needs different values:
| Type of data | Recommended TTL |
|---|---|
| Category page HTML | 5–30 minutes |
| Product price and stock | 1–5 minutes, or cache invalidation |
| Recommendations (static) | 15–60 minutes |
| Recommendations (real-time) | Not cached |
| DNS record (normal operation) | 3600–86400 seconds |
| DNS record (before a migration) | 300 seconds |
Invalidation as an alternative to a short TTL
Rather than setting a one-minute TTL on a product page, you can use cache invalidation: when the
price changes in the backend, the system explicitly removes the matching record from the cache. The
next request gets fresh data and every request in between is served from the cache. That combines
high performance with data that stays current.