Search code examples
design-patternsservicearchitecturemicroservicesgrpc

should Inter dependent microservices replicate data of dependent service


We have N microservices where N can be greater that 10. These N microservices depend on a Master Microservice M. So improving latency in our system we replicate bounded context information in each microservice 1 - N. I want to know more about it from external point of view, are we on right track or there is another way to handle such communication between microservices.


Solution

  • To summarize, there are N microservices each of which depends on some shared context. To improve performance, each of the microservices cache a view of the context locally.

    Whether replication is the correct approach depends on the specifics of the shared context. The benefits of local caching in a distributed system are loosely based to the following:

    1. What are the characteristics of the context?
    2. Is it acceptable for a stale view of the context to be used for a short time?
    3. How often does the context need to be accessed?
    4. What is the likelihood that a given local cache access will succeed?

    In my opinion, it is worth caching locally if:

    1. The context is not updated frequently.
    2. Using a stale view is acceptable for a short time.
    3. M can't handle the volume of reads from N or N can't afford the cost of reads from M.
    4. There is a high likelihood of finding a given context in the local cache.

    In certain setups, network calls can be relatively fast and handling the possibility of a stale context and properly sizing local caches has its own set of issues. However, if N services need higher throughput or M is bottlenecked and the data is well suited to caching then local caching is a reasonable approach. Distributed caching services may be considered if there is a large amount of data to be cached or if you don't want to handle cache invalidations manually.