I have two Microservices A and B. B Microservice has a large set of an entity called User. Microservice A stores the User entity in its own DB if User is configured by an agent.There is no flag available in Microservice B's DB to find if the User is configured.

If I want to find all the list of all unconfigured user by page (Set(B)-Set(A)), how should I go about querying if User data is too large in microservice B

  • Could you clarify why there is no such flag in the database B? Wouldn't adding the flag solve the problem? – COME FROM Dec 7 at 10:17
  • If you are using .net, then try SignalR. I dont know if SignalR is available for other platforms. – Yawar Murtaza Dec 9 at 19:53
  • @COMEFROM the schema with Microservice B's DB is fixed and there is no permission to edit the schema. Microservice B has only read permission on the database. – Puneeth mypadi Dec 10 at 11:04

You can precalculate your aggragate before querying it by either emitting events or using active record. It will create easy to read aggragate - although you need to take care of updates of your base entities. That's an expedient solution.

However, in your case it looks like you need to step back and rethink your design. Might be a case that your microservices or tables are split suboptimally.

There is no good way to do this. Because your data is split across multiple microservices, you need to join this data manually. So there needs to be some piece of code like:

def find_unconfigured_users():
  for user in B.all_users():
    if A.has_configured_user(user):
      yield user

This is going to be tedious and slow, but because you are using microservices you don't have any reasonable choice. (The unreasonable choice would be to access B's data directly, without going through the microservice interface.)

Where this functionality should live depends … possibly, this should be part of the Microservice A itself, i.e. part of the service that deals with configured users.

When data is split like this over multiple microservices this might be a necessary evil, or could be an indication of a deeper problem. Domain-Driven Design has the concept of a bounded context – a self-contained part of the problem domain your software system is trying to solve. One bounded context should not be split across multiple microservices!

You might want to check which bounded context which aspects of a User belongs to. Why is there a need to deal with configured and unconfigured users, and why is that distinct from users in general? It is legitimate if different bounded contexts have different but related concepts of a “User”, but you have to be clear how they relate. Here, it seems like one User entity is effectively shared across different contexts, and therefore causing problems. Possibly, the solution could be to include the configuredness of a user into the main User context (B).

“The schema is fixed” is not necessarily a good reason to avoid doing this, but perhaps cannot be influenced by you. No technological solution will be able to solve organizational dysfunction – especially not microservices. You'll then have to fall back to tediously checking every user, as in the code snippet above.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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