Stale data
Ada updates her display name. The database now says the new name, but the cache still holds the old one, and cache-aside will happily serve it. That cached copy is stale, and deciding when to refresh or delete cached copies is called cache invalidation. It is famously one of the hardest problems in practice because every option trades freshness against cost.
The two standard tools:
- TTL (time to live). Every cache entry expires automatically after a fixed time, say 60 seconds. Simple and robust. Worst case, users see data that is 60 seconds old
- Explicit invalidation. When your code writes to the database, it also deletes the matching cache key. The next read misses and fetches the fresh value
Most real systems use both: explicit invalidation for correctness, plus a TTL as a safety net for the deletes your code forgets.
Code exercise · python
Run this TTL simulation. Each cache entry stores its value plus an expiry time. We pass in a fake clock (now, in seconds) so runs are deterministic. Reads at t=0, t=10, and t=45 with a 30-second TTL.
Quiz
Ada changes her display name. Your update code writes the database and also deletes the cache key user:ada. What does the very next read of her profile do?
Choosing a TTL, and what caching buys
How long should a TTL be? Ask: how stale can this data be before someone is harmed?
- Account balance: seconds, or do not cache it at all
- A profile page: a minute is fine
- A country list: hours
The reward for getting this right is measured in latency. Average read latency with a cache is a weighted blend:
average = hit_rate × cache_latency + miss_rate × database_latency
With a 1 ms cache, a 10 ms database, and an 80% hit rate, reads average 2.8 ms instead of 10 ms. You will compute this yourself now, and this exact formula shows up in system design interviews.
Code exercise · python
Your turn: compute the average read latency for hit_rate 0.8, cache 1 ms, database 10 ms, using the weighted blend formula. Print it rounded to 1 decimal, then print the speedup versus going to the database every time (db_ms divided by the average, rounded to 1 decimal, with an x suffix).
Problem
Profile pages are cached with a 5-minute TTL and no explicit invalidation. A user changes their avatar right after their profile was cached. In the worst case, how many minutes can other users keep seeing the old avatar?