5

I'm fairly new to both microservices and shared in-memory databases like Redis.

I'm wondering though if it would be a good idea to combine the two to address the challenges of data duplication, sharing and ownership in a microservice oriented architecture.

Wouldn't it be a great solution to have microservices who need access to another services data simply join the cluster as a read-only slave node?
This way ownership (and write access) would still lay completely within the individual service, but access to the data would be very fast for every slave and even if the master goes down we could continue to provide some level of service from the slave.

Obviously the amount of data could be a limiting factor but other than that, what are the reasons this approach doesn't seem to be widely used?

Improve this question

1 Answer 1

Reset to default
17

Just like using a single database for multiple services, the approach you describe causes a strong coupling between the services. For example, you can not change the data model of one service without having to accordingly change the model in others. This means that both development and deployment are coupled and your microservices in reality become a monolith with multiple proceses. Since independent development and deployment of services are one of the important reasons to go with microservice architecture, without them you might build a monolith as well.

As with any pretty much any good practice, there are, of course, exceptions to what I just said. When used in limited scope, the shared cache may offer such an important performance boost, that it makes sense to forego the loose coupling of servcies. A reasonable situation would be for example two services developed by a single team, both with a narrow scope and needing to closely cooperate anyway. Think one service which fills the cache with data and another which reads that data. In this case you have quite strong coupling anyway and the shared cache, even though not so good form an architecture and maintenance point of view, may still be a reasonable compromise due to the performance benefits. But in a general case, such a shared cache is a bad idea (see above).

Improve this answer
6
  • Great points, thanks for sharing! Just before I completely dismiss the idea: what if we did decouple the data models and used the shared cache only as a shallow copy of the actual business objects? Basically instead of responding to requests through the API, expose the same data that could be requested in the shared cache. We'd still need to agree upon a schema but that's also the case in a standard API request/response and we still get performance and fault tolerance... Still a bad idea?
    – TommyF
    Commented Jul 15, 2018 at 14:31
  • 2
    @TommyF There is a difference between agreeing upon a schema in a REST API and in a database or cache. If you have a REST API, you can change it independently of the underlying database. You can completely change the database your service uses but keep the REST API the same and the client won't even notice. If you access the DB or cache directly, you can't do that and you end up with strong coupling. So the question remains: is the gain in performance big enough to offset the lack of flexibility? In some cases it might but in most it probably isn't.
    – Michał Kosmulski
    Commented Jul 15, 2018 at 19:51
  • Agreed. But there is one other fatal problem with this - you often use your memcached or redis server to save CACHED data, but can fetch/compute the underlying data if its not in cache. You need to call through a web-service-layer anyhow to do that computation when the data isn't found in your caching server.
    – Lewis Pringle
    Commented Jul 18, 2018 at 20:41
  • yes your example could be applied in a CQRS context, where a command-side microservice is able to invalidate a cache while the read-side microservice hits it
    – Carmine Ingaldi
    Commented Mar 10, 2020 at 7:23
  • In this aws design - aws.amazon.com/blogs/architecture/… - cache seems to be shared
    – RamPrakash
    Commented Feb 20, 2022 at 19:05

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.