Inter service communication in Microservices

Question

I understand the Event-Driven Architecture where a service subscribes to the events for inter-service communication. An event can be triggered when an entity is created/updated/deleted.. but how can inter service communication be achieved in case of GET requests.

For instance: A notification microservice which returns the list of product notifications for the end user - needs to read User's notification preferences (to which products he wants notifications), needs to get the basic product information (product name, price) and the notification service for the notification data itself.

This can be easily achieved by orchestrating all the services (preference service, product service) inside the notification service - but that would result into tight coupling there.

What's the proper way to implement inter-service communication in microservices when the data needs to be fetch from multiple services?

Answer 1

There's a couple of misunderstandings here and I'll try to list them out. Event driven architectures are not really for "inter-service communication". The term event here refers to things that happened to your system that might trigger state changes. For instance, as cliche as this example is "deposit" and "withdrawal" are domain specific events that have happened to your system. Deposit in this scenario is the addition of the transaction amount in the deposit event and withdrawal is the subtraction of the withdrawal event. Event driven architecture is effectively decoupling the data and the processing of the data.

This can be easily achieved by orchestrating all the services (preference service, product service) inside the notification service - but that would result into tight coupling there.

As per point immediately above, fetching data from multiple microservices may not be considered tightly coupling. It could also be considered cohesion. Cohesion acts as a form of coupling that respects the domain. For instance, if those preferences are specific to notifications, then its a notification preference and therefore can exist in the same service.

In order to manage the products you might want to receive notifications for, every time you create a new product, you can propagate the product name or identifier to an event bus with a "ProductAdded" event which the notification service might be interested in. The notification service can then create the product as an option that users can subscribe to to receive notifications. Let me know if all this helps and if I can clarify anything else.

Answer 2

Use a workflow system such as Argo.

In my terminology, the notification microservice is a composite service. The traditional way of doing this is to orchestrate the other services in an ESB - pretty similar to what you propose:

This can be easily achieved by orchestrating all the services (preference service, product service) inside the notification service - but that would result into tight coupling there.