I am not fond of using cache mechanism empty-headed just "to make things faster" except cases when it is absolutely necessary. Every time you add caching think about those two points:
- Cache statistics (hit rate, eviction count and etc.) should be easy to reach out and transparent for developers: it should either print statistics into logs or provide a way to look into it using remote connection (e.g. JMX connection). It is needed to see how performant the cache works because the data it was introduced to work with initially could change (and probably will change) with time and eventually it may no longer work correctly with the new dataset. This kind of change could lead to the situation when cache may become a bottleneck of your application and without proper introspection, it will be really hard to find the root cause of it.
- The cache should provide an API to make it possible to forcefully invalidate caches whenever it is needed: stakeholders are rushing with sign-offs but you should wait till invalidation time comes or (what is worse) simulate a fake action which will invalidate the cache.
As you can see introducing the cache mechanism requires additional operational costs which may not be obvious from the begging