2

In our microservice architecture, this is how requests flow.

enter image description here

Service Layer: Requests hit this layer from public LB. Also, response composition is performed here.

API Gateway: The core job of API gateway is to make parallel calls to respective microservices.

Please note Usually response composition is done at API Gateway. However, we intentionally moved composition at service layer due to frequent changes in compositions.

Being in the automotive domain, we deal with vehicles, dealers, leads etc. Now, there is a confusion on when to prefer synchronous over asynchronous and vice versa. Let me take an example of below two microservices.

DealersService: This service holds all the information about dealers.

LXMSService: This service is responsible for processing leads we capture on our platforms and send it to respective clients(dealers).

While lead is getting captured, we want to show the list of dealers user can choose from. The logic of showing dealers may vary client to client. These logics are configured in LXMS, and we store only dealer ids in this service(LXMS).

Now there can be two possible ways to show dealers!

Possibility 1: Synchronous way

Step 1: Make a call to LXMS microservice

Step 2: Get a list of dealer ids

Step 3: Pass these list if dealer ids to Dealer microservice to resolve.

Step 4: Dealer microservice returns id, name of a dealer which we show to the user.

enter image description here

Possibility 2: Asyncronous way

We remove the dependency by storing the dealer name in LXMS microservice. And maintain consistency using Pub/Sub. This way we are isolating LXMS and removing run-time dependencies from the service layer.

enter image description here

Here are the questions

  1. Which approatch we should go with & why?

  2. What is the problem in making sequential calls?

  3. In first approatch, when service layer making sequential calls. Can we call microservices independent?

  4. Isolation comes at the additional overhead of data synching using pub/sub. Is the isolation worth this overhead?

  5. When to prefer synchronous over asynchronous and vice versa?

Thank you!

  • 4
    Community: more than ever before, new users need guidance on how to ask good questions here. I don't see anything obviously wrong with this question, yet it still attracted downvotes (but no close votes). Communication is key. If you feel it's too broad, remember that this site was specifically created for questions that were broader than could be answered on Stack Overflow. Partial answers have always been welcome on Stack Exchange: pick the one that interests you from above, and answer it. – Robert Harvey May 28 at 16:23
  • 1
    The terminology synchronous vs. asynchronous here is a bit misapplied. You're asking about multiple microservice invocations vs. caching of one's data in the other to save a round trip. Classically the term asynchronous means timing independent of the main program flow and mechanisms to deal with the potential interruption of this main program. Messaging can be one-way or round trip, but it is usually a bit improper to refer to messages themselves (which are just data) as sync or async unless you're also speaking of internals of the code of a sender and/or receiver. – Erik Eidt May 28 at 20:42
3

I would recommend the asynchronous approach. The main thing this buys you is service autonomy, which brings many benefits. One of these benefits is better availability. If the Dealer service is down, you can still process leads. If you're already storing dealer ids in the LXMS, presumably you are already doing some sort of asynchronous communication to get these ids into the LXMS data store. You should be able to just add the name and whatever other data is required for the use case.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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