Caching.
Keeping the milk on the counter instead of walking to the fridge every time.
Some work is slow or expensive: querying a database, calling another service, rendering a page. If you are going to need the same answer again soon, why redo it?
A cache is a small, fast store that keeps recent answers close by. The first time costs full price; after that, you grab the saved copy almost instantly.
- All the way over there?1
You want milk. It’s in the fridge across the room — the slow, far-away source.
- 2
First trip is a miss: you walk to the fridge, pay full price, and grab the milk.
- 3
On the way back you leave it on the counter — a small, fast store close at hand.
- Instant. Lovely.4
Next time is a hit: the milk’s right there, no trip needed.
- Wait… is this off?5
The hard part: a cached copy goes stale the moment the real data changes.
- 6
So you set a time limit, or toss the copy the instant the source changes — cache invalidation.
The hard part: knowing when it is stale
A cached copy can drift out of date the moment the real data changes. So the whole art of caching is deciding when to throw a copy away. The simplest rule is a time limit (a TTL): keep it for sixty seconds, then refetch. The trickier approach is to actively clear entries the instant the underlying data changes.
There is a famous joke that the two hardest problems in computing are naming things, cache invalidation, and off-by-one errors. It lands because deciding when a cached copy can no longer be trusted is genuinely subtle.
Caches are everywhere
This pattern repeats at every layer: your CPU caches memory, your browser caches files, a CDN caches pages near you, and apps cache database results in memory stores like Redis. Same idea each time — trade a little staleness for a lot of speed.