Interservice communication in microservices

Question

Let's say we have four microservices: user, shop, subscription and product.
the user sends a request to add a product to his shop, we need to meet these conditions to add a product:

• user must be active (so we need to call to the user microservice and check it)
• his shop must be verified and enabled (so we need to call to his shop and check it)
• his subscription is not expired (so we need to check his subscription).

After checking that rules we can create a product in our product microservice for his shop.

I have two options:

1. sync call (from product microservice) to each microservice and check rules (but in this way all microservices have tight coupling).
2. using SAGA to check those rules and then create the product (but maybe user needs to see the created product in response)

What is the best solution, there is any better option?

Answer 1

What is the best solution, there is any better option?

One important thing to review is whether your service boundaries are actually aligned with your needs. The fact that the data you want for your calculation is scattered across many services is a bad sign.

If your services are going to be truly autonomous, then we want a design where everything still works even if no two services are ever running at the same time. With such a constraint, we're never going to be making synchronous calls between two services. Instead, we'll pass messages back and forth via some transport that doesn't lose messages when services shut down (a database, or a message store, or a message queue, or something that is decoupled from the question of whether or not the domain logic process is running).

In effect, we arrange that the service that needs to perform the computation will collect messages with (potentially stale) copies of the necessary data. Another way of saying the same thing: the data fetch from other services is data on the outside.

One of the important ideas of data on the outside? the data is not locked. You really do not want to be trying to hold simultaneous locks on data owned by different services.

Also, you should assume that the response to the user is going to be asynchronous. We probably acknowledge the message from the user right away, but that's just acknowledging that we've copied the request into a place where the service will find it.

Answer 2

In my understanding of microservices - these will be independent and loosely coupled by their nature - so best to treat them as such - assume they don't understand each others contexts at all. However these processes seem very closely related, to the point where the output of one is almost guaranteed to be an input to another.

User - sounds similar to identity/authentication, which could be excused as being a prerequisite to the other services - if not for auth, but for required context.

Other than that - this sounds like a question of - where is the process orchestrated? In the client (your option 1)? Or in another 'central' service calling the microservices on behalf of the client (your option 2)?

https://dzone.com/articles/microservices-using-saga-pattern suggests that event messaging could also be used to avoid a central service orchestrating the process - but each of the microsoervices would need to be subscribed to others events and know when to execute their own processes.

To me - If your services are truly independent ( like managed by different vendors, different code bases etc) then I would orchestrate at the client.

If this users User interface is only one of many (multipl applications that can create products)- then i would create 'central' orchestration service in something like an Enterprise Service Bus. This makes the orchestrated process reusable.

If you have full control over these all of these microservices and they are part of the same solution stack, then I would build the requisite rule checks into the product micros service, and make it one transaction. You could still do this RESTfuly using a POST/PUT command.

This would make a good diagram - happy to draw up if you feel it would help.

Open to your (and others) thoughts.

Chris