Components involved:
- Mobile Client
- Microservices
- API Gateway
Each microservice is a Flask application exposing a RESTful API. When a request is made by the mobile client, it is sent to the API Gateway.
One of the most important tasks of the system is to perform the furniture selection and furniture placement algorithms (as shown below). The selection takes place first and provides the output to the placement algorithm which should give the result to the user.
Once the API Gateway has the request, I have 2 options:
- The API Gateway sends a request to Selection Algorithm Service. Waits for its response. Once the API Gateway receives the response, it sends a request (along with the response received from the previous request) to the Placement Algorithm Service. Gets the response and returns it to the client. Illustration below:
- The API Gateway sends a request to the Selection Algorithm Service which does the required processing and then sends a request to the Placement Algorithm Service along with the result. Once Placement Algorithm Service completes, it responds back to the Selection Algorithm which sends the response back to the API Gateway and the API Gateway returns it to the client. Illustration below:
Also, if at all 2 microservices wanted to communicate with each other, what method would be used?
Best Answer
This feels like a false choice as presented, but also there are different kinds of dependencies to consider which have a different "right" solution. That said, I can't think of a single case where either of your proposed solutions is the right one.
As you worded it, Service B cannot provide its output without an answer from Service A. That's a red flag to me right away, and tells me they probably shouldn't be separate microservices. It also means that in the current architecture, the only way to handle it is for Service B to talk directly to A and provide a composed response to the client through the API gateway, and in point of fact it also is a red flag that there probably shouldn't be two microservices. If that's true, then the output of B does not actually "depend on" A.
If what you meant was that the service endpoint exposed by the API Gateway is a composition of information from Services A and B, then that's your answer; each one is independent and gets composed by the Gateway.
If what you meant was that service A has data Service B needs (just data, not business logic), then another answer might be a shared data store (either a traditional database or a message queue or whatever) that both microservices talk to.
There's a pretty good discussion on the options and "why" of service composition over at Auth0 that you might find illuminating as well, and it also might help us create better answers for you is if you provided your specific business case rather than using generics like "Service A" and "Service B".
After Question Update
In the case of your updated use case, I would restructure your options depending on what other uses of those microservices exist. In no case that I can presently think of would I have the Selection microservice directly call the Placement microservice.
Instead, I would either compose the work in the API Gateway as you described, or consolidate the microservices into a single component.
Providing a unified, higher-level API that manages multiple service call upstream is well within their scope, imo. The main reason you might not want to do this is if there are technical limits to doing so, for example if there are a lot of chatty calls between the two microservices that need to happen to resolve one client request. That might be the case for example, if you wanted to provide a client service that optimizes "best fit" analysis, both of selecting the furniture and placing it and in doing so you need to select a piece and place it in many combinations. If that's the case, I'd consider making one "Room Design" microservice that handles all that internally, which may let you optimize the database and queries better and so on.