I'm developing a doctor-patient system that consists of two microservices, namely the "doctor" and "patient" microservices. Both doctors and patients share some common attributes, so I introduced a third microservice called "users" to manage these shared attributes. However, I'm unsure about the most suitable approach for messaging between these microservices.

I have considered two valid scenarios, and I would appreciate guidance on choosing the most appropriate one:

Scenario 1: In this scenario, the client directly calls both the "users" and "doctor" microservices, providing the relevant information that each microservice manages. The client would make separate API calls to both microservices. Client can be a composite service within the same kubernetes claster

Scenario 2: In this scenario, the client only calls the "doctor" microservice, providing all the required information. Then, the "doctor" microservice internally calls the "users" microservice to process some additional information while handling the rest of the information itself.

I would appreciate advice on choosing the most suitable scenario for my system, along with the reasoning behind the recommendation.

Thank you!

  • 3
    Microservices aren't nouns - you don't create one every time you see a noun...
    – user253751
    May 16, 2023 at 16:40

3 Answers 3


Microservices aren't nouns. You don't create a new microservice every time you see a noun. Microservices should be defined in ways that make sense for microservices, not just because.

And it makes absolutely no sense to do "microservice inheritance". There is no sense having a "users microservice" and a "doctors microservice" that "inherits" from "users".

Microservices are mostly independent and self-contained. Yes, they can sometimes use data from each other, but not heavily. If you find they're constantly interwoven then you chose the wrong microservices to make.

Classic example of microservices are things like billing, authentication, recommendations. They are mostly separate. Something sends a bill to the billing system, and then the billing system handles making sure the user pays their bill. The user logs in with the authentication system, and now they are logged in. Possibly, each other service needs to check to see if the user is still logged in, but that's all they have to do with authentication. The recommendations system needs to know who bought which products together, but it calculates the recommendations by itself. There are points of contact, but each system is mostly doing their own thing. The billing system just needs to know which user is logged in; it doesn't need to know whether they used a password or a security key.

Also notice that microservices do things. The billing system does billing. The authentication system does authentication. The recommendations system calculates recommendations. They don't "manage data", whatever that is. You could say the billing system "manages billing data" but surely it's more logical to say it "does billing"?

Now, your system is a healthcare system, and I presume not a surgery robot, so obviously the system can't "do healthcare" and its purpose is to "manage data" to help the healthcare workers "do healthcare" more effectively.

Note that a service which only manages data is called a "database" and is not usually considered to be a microservice.

One of the main reasons to use a microservice architecture is that different teams can work independently on different microservices. If your company would have a doctors team and a patients team, maybe it would make sense to have a doctors microservice and a patients microservice, but you don't.

Another reason to use microservices is to contain faults - if the authentication service is down then people who were already logged in are still logged in. If the recommendation service is down then people can still watch movies, but they don't see recommendations for other movies. This doesn't happen in your case because "doctors" and "patients" are strictly dependent on "users" for, presumably, every single request.

Conclusion: you probably shouldn't have doctors and patients and users microservices.

In a comment you identified that you could make a search microservice. That would make sense. Search is quite separate from the rest of the app - it just needs the list of doctors, which you could import once per day (to keep it simple and stupid) as it presumably doesn't change very often. Then the search service could operate completely independently. Data import broken? No big problem, search still works but it searches yesterday's data, which is mostly the same anyway. This would be a good microservice.

In a microservice architecture you value separating the microservices more than you value not duplicating the data. Making the search service get the updated doctor list every time someone does a search is considered much worse than letting it have its own copy of the doctor list, because it means the search service stops working if the "doctor list service" is down. When the search service has its own data, it continues working.

  • I respectfully disagree with the notion that microservices should only be considered when there is a dedicated team in place. As a beginner in microservices, I believe that the value of microservices extends beyond team management. For instance, I see a valid use case for a microservice to serve as a database, where it can enforce domain-specific validation rules for a particular entity, such as doctors. Other services can then interact with this microservice instead of directly accessing the database.
    – omid
    May 16, 2023 at 21:12
  • @omid why doesn't the Doctor class do that? why does it need to be a whole new service?
    – user253751
    May 16, 2023 at 21:17
  • This is my reasoning. In our patient app, we have implemented a search functionality where patients can enter unstructured text in a text box to search for doctors. The search query could include a doctor's name, expertise, or any relevant information. Now, I am considering adding a new service specifically dedicated to searching doctors. My rationale for not including this functionality within the existing doctor service is based on scalability. The search functionality is expected to have a significant load, as it will be heavily used by patients.
    – omid
    May 16, 2023 at 21:49
  • On the other hand, the doctor service itself is primarily used during the new doctor sign-up process. By separating the search functionality into its own microservice, I can scale and optimize it independently from the doctor service. This allows for better resource allocation and ensures that each service can handle its respective workload efficiently.
    – omid
    May 16, 2023 at 21:49
  • @omid Okay! You have identified that maybe you can have a doctor sign-up microservice and a search microservice. Neither one has the job of managing data and nor do they inherit from each other :) Search is often a good candidate for a microservice, basically for the same reasons that recommendations is.
    – user253751
    May 16, 2023 at 21:50

How you decide to communicate between Microservices doesn't depend on domain context, so for the moment, you can forget all about your doctors and patients.

What seems to be the preferred way is to use an event messaging model. (although nothing is settled as far as I know.)

So instead of thinking about the Doctor and Patient, think about the things that could be said to happen, events, that your Doctor would subscribe/listen to, and do the same for your patient.

This will allow you to change the angle that you are approaching the system from and capture a broad range of inter service / object communications, in a decoupled and extensible way.

So you can meet the broad requirements of a healthy microservices system

  • Loosely coupled
  • Maintainable, testable, and traceable
  • Can be independently deployed

Further reading on event based communication between microservices is encouraged, it's a big topic and really does represent a major shift in mindset.


To build on @ocodo's answer one possible answer might be to draw the following conclusions:

  • Most of the shared attributes (between doctor and patient) are security/login related, hence they can be pulled out to a separate service that handles that.
  • The majority of the data about interactions between doctors and patients can be stored with the patient.
  • Hence the doctor side of the model is much lighter - just a reference to the patient service.
  • The doctor specific functionality would be limited to managing ToDo lists and calendaring (busy/available etc).

To be clear I am not saying this is "the answer" just trying to give an example of how you could think about the problem to try to minimize inter-service communication.

In this design some data is duplicated, for example:

  • The doctors have a list of patients.
  • Potentially the Patients have a list of doctors.
  • Both sides have an "appointment"

I would be tempted not to create an "appointment" service, because doctor and patient appointments are very different (for example you don't have the patients calendar), hence the functionality can probably live in both services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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