3

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?

Community
  • 1
  • 1
rayman
  • 20,786
  • 45
  • 148
  • 246

1 Answers1

2

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.

Rabea
  • 1,938
  • 17
  • 26
  • the prob here that using this approach:1. if user realy has to take action with his state result it might even cost me a 3rd call(e.g refresh user details from user-service) so if iam doing a second call to check a state I could instead request straight from the user-service. get me? – rayman Feb 12 '16 at 08:23
  • I understand, I would consider measuring how often my user changes his state compared to the whole system logic, and if it it not a huge part of the system, then I won't worry about it. and again, you are debating bypassing the concept of micro services, which at the end was created to manage tech components and teams in more efficient way, if you move forward without that , then number 3 is also a possibility. – Rabea Feb 12 '16 at 15:52
  • you think 3 will be better than 2? while duplicating user-data(only user-state) for each service – rayman Feb 12 '16 at 16:03
  • 2: you mean replicating all data between instances of different services whenever there is a change ?, if thats the case, it will start to be a replication hell. I would prefer dealing with code than dealing with data integrity all the time. – Rabea Feb 12 '16 at 19:08
  • yeh that what's i meant...it's this vs create a new service and all the hassel. around it just for user-state api – rayman Feb 12 '16 at 19:09
  • if you do not see the user service as a product by itself, then I am with that it does not have to be a separate service. – Rabea Feb 12 '16 at 19:15
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/103333/discussion-between-rabee-abdelwahab-and-rayman). – Rabea Feb 12 '16 at 19:20
  • 1
    Userservice is a service by itself but user-state is just api against redis. iam decouping btw the two coz.userservice is a heavy component while userstate is only api call(wrapped by vertx) to redis – rayman Feb 12 '16 at 19:29