Microservices architecture domain context

Question

We have two microservices a person service and a resource service. The person services stores the general person details, name, address contact information etc. The resource service would store details about the person if they have a role of Teacher, eg. what subjects they can teach, along with their name.

When creating a person you could create them as a teacher and therefore the person service will store the main person details and the resource service will store the teacher information. We're thinking this should be a Saga then as we'd be storing information about the person in two different services? Would this be correct?

Secondly, if that is correct, when the saga completes what message or messages should go on the message bus to say Person has been created and they have teacher details too? Should there be one message that says PersonCreated with all the details of the person and the teacher? Or two messages one of PersonCreated with those details and another TeacherCreated which is the resources view of the Teacher?

Answer 1

Before answering, it is necessary to understand two things:

• Microservices are independent from each other and have a limited context. This means that while they relate to each other, microservice A only knows a part of microservice B and vice versa;
• Sagas are used for processing asynchronous transactions and must adhere to the concepts of commit and rollback.

For your first question, yes! Saga may be used in this case. Now, regarding your second question, it is important to understand the event creation structure. A triggered event should contain enough information for its listeners to interpret it according to their needs.

In practice, the Person microservice is the entry point for creating a new person. So, you have two options for communicating with the Resource microservice:

1. The Person microservice will emit the PersonCreated event containing all the necessary information for the Resource microservice to interpret (such as job role, job metadata, etc.), as well as for all other listeners (person ID, name, address, etc.). The Resource microservice will read this event and determine what needs to be done based on the payload;

• In this specific case, the microservice that will receive from user interface all the information, including the information about the person's job role and its metadata, will be the People microservice.

2. Your user interface can have a "complete profile" step after creating the person, where the resource data will be created and sent directly to the Resource microservice.

• In this case, you are exposing the Resources microservice and making a direct request to it (POST /person/:id/resources) without working with events.

⚠️ It is also important to note that Sagas have a dependency relationship. In other words, if the Resource microservice fails to process the PersonCreated event, it should emit an event to have the previously created Person removed.