Invalidation is the design problem

Time-based expiry is the simplest and the most honest: the data may be up to N seconds old and everyone knows it. It needs no coordination and it fails safely, and for a great many things, a product list, a public profile, a dashboard of yesterday's numbers, it is the whole answer. Choose N by asking what a user would actually notice, not by picking a round number.

Event-based invalidation is exact and much harder. Something changes, you purge the affected keys, and now every write path must know every cache key it affects, including the composite ones, like a list page that contains the item you just edited. Tagging helps: attach tags to cached responses and purge by tag, so an edit to a product purges product:42 and everything tagged with it without enumerating URLs. Order matters: purge after the write is committed and durable, or you will refill the cache with the old value.

Then plan for expiry itself. A popular key expiring under load sends every concurrent request to the origin at once: a thundering herd on the exact resource that needed the cache. Serve stale while revalidating, or let one request rebuild while the others wait or take the stale copy. A cache without this behaviour turns a traffic spike into an outage precisely when it is doing the most good.