Time-to-live and stale data
How long may an answer be reused before it is too old?
Cached data becomes stale when the original changes. A restaurant raises the price of a pizza, but the cache still shows the old price. A time-to-live (TTL) limits how long an entry may be reused: after the TTL passes, the entry is treated as expired and the next request fetches a fresh copy. TTL is the simplest tool for bounding staleness, because you do not need to know when the data changes, only how old an answer you can live with.
Different data tolerates different staleness. A restaurant's description can be a day old. The number of riders near you can be 30 seconds old. An item's stock count during a flash sale cannot be old at all, and you may decide not to cache it. Choose the TTL per kind of data by asking what the worst consequence of a wrong answer is, not by picking one number for everything.
Watch entries expire
The same key is requested 12 times in a row with a 3-request TTL. Raise the TTL to 6, then remove it. Notice how expirations turn would-be hits into misses.
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
- Apending
Cache (next to evict ← → most recent)
Press Step to begin.
In the simulation the TTL counts in requests to keep it simple; in a real system it counts in seconds. The shape is the same: with a TTL of 3, every fourth request finds an expired entry and goes to the database, so the hit ratio is 8 of 12 (67 percent). With no TTL it would be 11 of 12. The database load is the price of freshness.
Your turn
Pick a TTL (seconds, minutes, hours or no caching) for each: restaurant menu text, delivery-time estimate, a customer's wallet balance. Justify each in one line.
Stuck? Ask what happens if the user sees an answer that is old.
What to remember
A TTL bounds how stale a cached answer can be.
Expired entries count as misses, so a shorter TTL lowers the hit ratio and raises database load.
Pick the TTL from how quickly the data changes and how much staleness users tolerate.
Add jitter so expiries do not line up.