Caching is introduced as an optimisation and then quietly becomes part of the system's correctness model. Every cached value is a decision that stale data is acceptable here, for this long — a decision usually made implicitly by whoever picked the expiry.
Decide the staleness you can tolerate
A product description can be minutes out of date with no consequence. A stock level cannot, if you sell the last one twice. A permission check certainly cannot.
Start from what a wrong answer costs, not from what performs best. The expiry follows from that, rather than being chosen and then justified.
Invalidation is where it goes wrong
Expiry-based caching is simple and its worst case is bounded. Explicit invalidation is more precise and much easier to get wrong, because every path that changes the data must remember to clear the cache.
The failure mode is subtle: data that is correct in the database and wrong on screen, which sends everyone looking in the wrong place.
Watch what caching hides
A cache in front of a slow query makes the symptom disappear while the underlying cost remains — and grows. The day the cache is cold, or a deployment clears it, the system meets the real load for the first time.
Fix the query where you can; cache to avoid unnecessary work, not to conceal necessary work you have not done.
Cache per user carefully
The most serious caching bug is serving one user's data to another, and it happens whenever a cache key omits something that varies per request — the account, the locale, the permission set.
Anything user-specific deserves an explicit review of the key, because this failure is invisible in testing and severe in production.
Write down, next to each cache, what may be stale and for how long. That single line converts an invisible assumption into a reviewable decision.