TTL is a freshness policy#
A TTL answers: how long are we willing to reuse this entry without checking the source again?
A short TTL usually means fresher data and more origin traffic. A long TTL can improve hit rate while increasing stale-data exposure. No TTL requires another dependable invalidation or capacity policy. Expiration may make an entry unusable; it does not coordinate every concurrent reader or repair missed write invalidations.
Choose a TTL for product prices
| Candidate | Benefit | Cost |
|---|---|---|
5 seconds | Short stale window | More misses and database reads |
30 minutes | Higher reuse and lower origin load | Potentially unacceptable old prices |
The product requirement decides. A browse page might tolerate bounded staleness; checkout should revalidate correctness-critical price and inventory before committing an order.
Jitter prevents synchronized expiry#
Ten minutes later, a large fraction can expire together and expose the origin to synchronized misses. Add bounded randomness so expiry times spread across an interval:
entry TTL = base TTL + random jitterThe jitter range should follow traffic, freshness, and recovery requirements; one fixed percentage is not universal.
- Treating TTL as a complete invalidation strategy.
- Choosing a round number once and never measuring hit rate, age, or origin load.
- Giving correctness-critical and best-effort data the same lifetime.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Caching challenges and strategiesAmazon Builders' Library
- EXPIRE commandRedis Documentation