Why NOT to Cache
I’ve worked over the years on a lot of projects, with many teams. Frontend, backend, mobile, and so forth. One topic that always comes up - caching. Developers love to talk about the topic, and are excited to add seemingly low-cost performance enhancers to their architecture and code base. However, as Martin Fowler and many others have pointed out, caching is evil. It’s one of the hardest problems in computer science to solve.
The typical pattern is to take a slow request - say, an API response - and store it in a local cache (perhaps to disk, or Redis). The implementation goes like this: the simple approach is to do a get/set cache lookup. When the user needs the data, check if it’s in the cache. If it’s not, or it has expired, then fetch the latest value and store it in the cache.
For apps, one side effect of this approach is degraded experience for some small group of users. For example, a web app needs to access a slow resource that takes 2 seconds to respond. With caching used, tha