3

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?

8

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).

  • 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 Jul 15 '18 at 14:31
  • 1
    @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 Jul 15 '18 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 Jul 18 '18 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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