0

We have services A, B and C.

Service C is connected to Redis while Services A & B (via API) requesting objects from service C

We dont want to share C's redis with A & B (straight forward) to keep the datasource isolation rule.

The disadvantage that we pay with latency as we request some API's calls (specially on peak times)

We want to use some In Memory data grid solution as we found out we mostly cache things inside the service ram.

we considered hazelcast but thought that redisson can make it work smoothly as we already using redis.

My concerns if we use redisson IMDG solution we will heart the microservices architecture as services A & B will reach to C's redis straight forward (and not via API)

thoughts?

rayman
  • 20,786
  • 45
  • 148
  • 246
  • With hazelcast you should also share your memory between A, B and C microservices if you want any communication between them through hazelcast. – Nikita Koksharov Jun 19 '20 at 15:31
  • You right, so you sharing datasource between all services which kind of destroying the isolation – rayman Jun 19 '20 at 15:32
  • As option try to use database setting. So you'll get ability to use the same Redis setup, but each service will use own database. – Nikita Koksharov Jun 19 '20 at 15:35

1 Answers1

0

For your specific use case you can definitely use a data grid such as Hazlecast or Infinispan. The only drawback will be data replication/duplication in all 3 microservices which will consume memory equally in all microservices. If you are thinking about using Redis as caching solution to share objects among the three services then you will save up on memory while keeping the databases for each microservice separate. So, it all depends on how you are planning to use Redis in your architecture.

Shivendra Kumar
  • 11
  • 2