4

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:

  1. 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:

enter image description here

  1. 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:

enter image description here

Also, if at all 2 microservices wanted to communicate with each other, what method would be used?

Improve this question
2
  • I think you may have option 2 backward: In that option, if Service B depends on information from Service A, the API Gateway should call Service B, which then contacts Service A to retrieve the needed information.
    – Bart van Ingen Schenau
    Dec 5, 2018 at 14:46
  • @BartvanIngenSchenau Lets say that's the case. But which option would be preferred?
    – Shahlin Ibrahim
    Dec 5, 2018 at 14:52

1 Answer 1

Reset to default
2

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.

Improve this answer
7
  • Your third paragraph, that's what I meant. Although is it really okay if the API Gateway sends requests to multiple APIs synchronously? Or is that bad design?
    – Shahlin Ibrahim
    Dec 5, 2018 at 16:29
  • 1
    @ShahlinIbrahim There are very few objectively "bad designs" in my opinion. There may be designs which better suit certain requirements than others, so it's hard to say without knowing what you're actually doing. That said, having a Gateway that composes an API response from several microservices is not uncommon, it's just not the best thing in all situations. Tell us more about your actual business problem and I can give better advice.
    – Paul
    Dec 5, 2018 at 18:26
  • I have edited the question and added an example of the business problem
    – Shahlin Ibrahim
    Dec 5, 2018 at 19:16
  • 1
    No, I'm saying that not everything needs to be the smallest possible microservice. Microservices should be logical chunks of work, which might mean that they do more than one thing under the hood (in your programming language of choice). If nothing else talks to the Furniture Placement service except the Furniture Selection service, then you don't need them to both be web-accessible services. Even if other things need to talk to both, it might make more sense to expose them as different API calls on the same service.
    – Paul
    Dec 5, 2018 at 19:59
  • 1
    This is the how I'm planning on solving the issue. Have one service called Room Design which contains two packages or libraries - Furniture Selection and Furniture Placement. This way they're still separate packages and can be independently developed but can also be put together using the Room Design Microservices
    – Shahlin Ibrahim
    Dec 6, 2018 at 6:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.