In microservice architecture, when to prefer synchronous over asynchronous communication and vice versa?

Question

In our microservice architecture, this is how requests flow.

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.

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.

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!

Answer 1

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.

Answer 2

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.