Tight coupling between micro services

Question

I have got the following scenario, which I have been thinking what would be the "best" way to solve it.

Request comes from the FE, which changes the status of a delivery, and that should trigger different things depending on the value of the new status.

-if confirmed, send email and also create pdfs -if dispatched, create pdfs and send some other emails to different people.

The way we are approaching this is: FE changes status to dispatched -> http call, controller receives the events, handles validation and so on, then updates the db, that in turn trigger an event DeliveryDispatched, which we handle asynchronously. That event handler would then create the pdfs and send the appropriate emails. All fine and dandy.

The scenario that we are facing, is that business finds out a new requirement, which wants a different field in either the email or pdf, then the solution we currently have is to add that to the creation of a delivery, and that's where the "problem" begins.

Why? new field is based on something that we already have an id from. So in this case, let's say, that we have the customer Id, but we also need the customer name, so an option would be to with the customerId that I already have, request the customer service, for that particular customer, which would give me the customer name, or any other additional relevant to the customer that I would need in the future. This keeps the change local to where it's going to be used

The "problem" with this approach, since we use microservice, is that this request is an http call, therefore, we have tight coupling because what if your service is down problem?

With that in mind, how would you go about that? Keep adding more and more fields in the first request when creating a delivery, and running migration for the case of old ones? What are the alternatives/best practices?

Answer 1

First let's point out that having an http call in between is not tight coupling. Tight coupling means that the interfaces are designed in such a way that every minimal change on one side (provider/consumer) will cascade requiring a similar a change on the other side.

If your interface has only the fields strictly needed for the basic behaviour in such a way that it needs to be changed for every new request coming from business then, yes, you have tight coupling. The design of the interface should take into account possible future changes. In the case of the customer name carrying the field around will impact less the performance than adding an http call to retrieve it later. But how many fields you can add as business requirements change is something that depends on the performance of your network, speed would encourage to add fields to the interface, low latency would encourage to add requests.

If you want to reduce the coupling you should think if you can put the fields you need in wrapping object instead of defining them explicitly in the interface. Then you could parse the objects with a shared library.

If, in the case you described, for one reason of another you are forced to keep the new http call it should be easy to handle the service down situation. Since your service is asynchronous just fail and retry later.