Caching Trades Freshness
How wrong is an answer allowed to be in exchange for arriving instantly?
The idea
A cache returns a stored answer instead of recomputing it, which is faster and may be out of date.
In the real world
A dashboard shows yesterday's totals for an hour after the figures are corrected.
Going deeper
Every cache encodes an answer to a question nobody wrote down: how stale is acceptable here? A one-hour cache on a marketing page is invisible. The same cache on a price is a commitment to sell at yesterday's number for up to an hour.
The two ways out are different in kind. Time-based expiry is simple and always wrong by up to the window. Event-based invalidation — clearing the cache when the underlying thing changes — is correct but requires every writer to know about every cache, which is where the famous difficulty lives. Choosing between them is really choosing who carries the complexity.
Where it stops applying
For data that is expensive to compute and tolerant of staleness, a long window is simply correct and invalidation is over-engineering. The question is always what a wrong answer costs, not whether staleness is theoretically undesirable.
Why it matters
It tells you that every cache is a decision about how stale an answer is allowed to be.
Try this today
For one cached value, write down how old it may be before it misleads someone.
Test yourself
A pricing page is cached for an hour. Finance corrects a price at 10:05. A customer buys at 10:20 at the old price. Who is at fault?
Show the answer
Nobody broke; the staleness window was set at an hour and the system did exactly that. The fault is in the choice, not the execution: prices needed either a shorter window or explicit invalidation on change.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.