How to handle shared datasources using microservices architecture

3
votes

I have couple of services in my microservice architecture.

Two of the service(Service A, Service B) got different api's and provide different domain logic. However they do share some logic that should be returned - user-state from Redis.

  • When user state is changed Iam publishing from a 3rd service to all the my micro-services

solutions:

  1. I could create another service which would be responsible for "user-state" and will hold all user data on Redis. Disadvantages: My clients going to have additional call on every api requests(to get the user-state).

  2. Duplicate the user-state datasource for each microservices(holding more than one redis instance) and return it independently for each request. Disadvantages: I am going to duplicate my data and duplicate Redis instances(each microservice will access it's own)

  3. have one redis datasource while all services going to use it. Disadvantages: Duplicating redis-logic(in order to retrieve the data) among the services and break microservices principle by using one shared datasource

What would you suggest doing?

1
javaarchitectureredismicroservicesbigdata

1 Answers

2
votes

I will definitely go with number 1 if you want to keep the micro services architecture solid; in the case where you see the "User/User State" as a totally separate product that can function by itself.

I think that an extra call to prevent redundant implementations/data is the way to go, if Redis is behind it, and the API in front of is performing then you should not have a problem with the extra call. and you get a win by keeping your system as decoupled as possible.

If that is not the case, then 2 will be a good solution. you will be faced by challenges regarding data integrity and replication problems, but it is one of the methods.