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. May 28, 2020 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, 2020 at 20:42

2 Answers 2


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.


I don't use Microservice architecture (Conceptual or Practical), but:

LXMSService doesn't seem to have a well-defined purpose. It should either be a CRUD gateway; or an Orchestration service, not both. When you are reaching across two tables/collections that requires orchestration.

Concept 3 - Orchestration to Dependencies:

  • Have a DealersForLeadService, that uses LXMSService and DealersService
  • DealersForLeadService MAY be defined on the client-side which is basically Possibility 1; or
  • DealersForLeadService MAY be a microservice on the server-side

Concept 4 - Orchestration to DB:

  • Have a DealersForLeadService, that bypasses CRUD microservices and talks directly to the database.
  • This would be a Microservice on the server-side
  • (It is possible to do this on the client-side)

Concept 5 - The Microprocess Architecture way

As eluded to in Concept 4 "(It is possible to do this on the client-side)", it's possible to query the database directly from the client-side using SQL. see https://colossal.gitbook.io/microprocess/definition/data-web-gateway. (This is better than GraphQL). All you really want is a View that is secured to the user context.

In a sense, the "Microservice" becomes the View definition itself. However, in reality, the database-web-gateway itself is the "data service" that doesn't need any custom code.

With Microprocess Architecture, you can totally remove the need for any Microservices, and only need the database-web-gateway and background microprocesses. You won't need the API Gateway, nor dedicated service layers.

While you may be modelling a real-world complexity, you should be handling that complexity with simple technology.

Your Answer

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

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