This is something I see not being much discussed within development teams. It’s almost as if there’s some kind of fear of serving stale content, or an internal assumption that information should be always fetched and guaranteed to be fresh by the second.

Here’s another (kind of) hot take for this calm Monday morning: there’s a very finite number of reasons to not use a caching strategy. In fact, I believe it should be something we default to using unless proven otherwise.

Here’s a basic strategy to cache and refresh data: many of the data I usually see applications manage are mostly updated through specific side effects or endpoints. This is a perfect use case for caching on updates: refresh the cache whenever the data is explicitly updated and always try to serve from the cache whenever that data is being retrieved.

Even in more complex workflows, where parts of the data must be fetched or go through some type of real-time calculation/transformation/etc., when the request comes in, we can always:

1. Fetch the cached base data from the cache.
2. Fetch or calculate only the needed “real-time” data from the appropriate data sources.
3. Compose and serve the entire information.

Caching data also creates a temporary redundancy in our systems. As long as the TTL (Time To Live) of the data hasn’t expired, the underlying data source can be offline because we’re still going to serve the cached data. The response times will go down, too.

I’m generalising, of course, but it should give a push into, at least, initiating a discussion on your particular cases if caching could bring benefits.

It’s better to discuss and conclude that it’s not something you want to add, rather than not discussing and continuing to invest computational power and service communication to always fetch fresh data without needing it.