CODEWITHSUNDEEP
spring-bootmicroservicesorchestrationmule-esb
UserMan
UserMan

Reputation: 471

how Orchestrate microservices

I've been triying to migrate part of our soa architecture (Mule ESB) to microservices (Spring Boot stack), but I'm facing a problem related to large flows where we have several orchestations. Basically We a have a flow which has an user id as input and the response is compounded of user account, creditcards data, stocks and loans. In this flow we have, at the beginning, a splitter (allows to send concurrent requests) and we send requests to account backend, 3 different credicard partners, stock partner and loans partner, at the end there is an agregattor (wait to all responses and merge all of them) and finally a node for prepare the response (apply business logic).

During the migration we have developed an account microservice, loan microservice, stock microservie and creditcard microservices (1 for each partner). The problem here is the orchestation, We can't use and event model approach because we need to get all responses in a certain point. We considered the choreography approach too, but we don't want to add logic related ot how orchestrate calls to our microservices because that would be a stepback to heavy coupled services (N*N connections).

We are thinking on make a new microservice that will be used as an orchestrator, but we don't know if this will be a good solution for microservices concepts.

Note: The front end can't make the orchestrations because it is a closed product and we can't touch it.

Thanks in advance.

Upvotes: 1

Views: 1552

Answers (1)

Oswin Noetzelmann
Oswin Noetzelmann

Reputation: 9555

We are thinking on make a new microservice that will be used as an orchestrator, but we don't know if this will be a good solution for microservices concepts.

From all you described that sounds like the most reasonable thing to do. You describe this service as having its own business purpose which indicates to me the potential need for a dedicated service. And the fact that it requires input from other (more basic) services would not be unusual for a complex domain service. Also you already listed the alternative of aggregating on the front end as something that doesn't work in your domain.

Something to consider is just making sure that the development teams for the basic services treat their APIs as customer facing (with the customer being your other services). That means they have to do clean work in terms of versioning/deprecating/etc. And the downstream services need to treat the consumed APIs like they would a 3rd party API. For example Google went so far to allow internal service consumption be charged real money to incentivize optimizing the implementation of dependent services.

Upvotes: 1

Related Questions