Let's say we will not use distributed caching because we want that our microservices are independent and they do not have many single point of failures. Either we will have in-memory cache (simple hashmap in every microservice instance) or we will have one REDIS per service kind.

If the service A needs some data from the service B then it will cache the value in REDIS-A. Here comes the problem: when B changes the data after receiving some PATCH request, how it can also invalidate the data in REDIS-A?

Let's say we do not want to use any form of messaging for it (is it not overkill?)

  • 2
    A is responsible for its data and B is responsible for its data. Period. If A needs to have very up to date data from B, it should refresh its cache often. B doesn’t know it has to tell A it got new data. Mar 8, 2019 at 14:38
  • A distributed cache should never be a single point of failure. If you can't pull from the cache you go to the source. Have you considered that this premise might be wrong and the simple solution is to use a distributed cache? Solving this kind of problem is basically why they exist.
    – JimmyJames
    Mar 8, 2019 at 16:46
  • On a side note, anytime you use a cache, you need to understand what your tolerance is for stale data. If there is none, you shouldn't be caching.
    – JimmyJames
    Mar 8, 2019 at 16:49

1 Answer 1


Oh, the joys of distributed systems. There are two general approaches to this problem:

You can keep using this caching strategy and accept that service A will usually get outdated data. This is just a performance vs consistency tradeoff. You can tune this tradeoff as necessary, for example by expiring cache entries after an acceptably short period of time.


You can stop maintaining a cache for service A. Instead, it always contacts service B directly through B's normal API, just like a normal microservice.

It is then service B's responsibility to somehow answer this request. For example, B could maintain a cache for recent requests. B is also in a position to expire cache entries when the data changes, thus being able to provide consistent responses.

This caching is internal to B. A does not need to know about this caching and can simply benefit from it by using B's normal interface.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.