Communication performance between microservices

0
votes

in this article on Microsoft, i've read this:

"The more you add synchronous dependencies between microservices, such as query requests, the worse the overall response time gets for the client apps.

" is it true? i think that in a synchronous communication we get feed-back more immediatly than an asynchronous communication. For example, imagine that a user send a http request to a microservice A which in turn send a request asynchronously to an another microservice B, and waiting reply of it asynchronously. If microservice B is down, then the user will waiting until a time out to get a response while in a synchronous communication he will get immediatly a response.

2
performanceasynchronousmicroservicessynchronous
I think the article is referring to call chaining (eg caller -> service A -> service B - service C and back). Which does introduce latency. - tom redfern
There are a lot of trade-offs between async and sync approaches, and they both have their place, but just two points that popped while reading your question 1. under the hood there is nothing "immediate". asynchronous means implementing your timeout on business logic layer. Synchronous means the timeout would be implemented in a lower layer, i.e. you can't keep executing as you are waiting on your function. 2. MS quote doesn't say their is no problem with asynchronous systems, it says something that is fairly obvious; As your dependency chain gets longer your response time gets worse. - hazirovich

2 Answers

0
votes

While technically it is possible to wait for an "async" message reply, you should not. So the two architectures are not entirely isomorphic. "Async communication" usually means a reactive model in the area of microservices, with fire-and-forget messages in some event-bus. It changes the user-experience too so it may not be applicable to all businesses.

Given your example, if microservice B is down

  • Synchronous case: your call-chain fails and the error is reported to the user.
  • Reactive messaging case: service A sends a response immediately to the users that the business-transaction started, and they will get a final result later. If B awakes, it will process the message and can send a reply through e.g. an open WebSocket (if any) to the client.

If microservice B is up

  • Synchronous case: A will wait for B to process the request so it will delay the response. The more services are in the chain, the more delayed the response will become
  • Reactive messaging case: the same as above, A returns immediately, etc...

As you see, with a reactive case the request is not delayed due to a long processing chain, instead, it changes the user-experience by reactively sending intermediate results as the process progresses. Of course, your business must support this kind of transactional model.

0
votes

Both styles of communication are necessary depending on the situation. Of course communication between microservices introduces latency, but without inter-service communication, you wouldn't be able to build anything useful!

Synchronous Communication usually involves making http calls between microservices. It's necessary when you need data from another service immediately in order to complete an operation.

Asynchronous Communication is great when you don't need immediate results to complete an operation. Imagine triggering an update in another service for eventual consistency. Another use-case would be triggering background processing (e.g. generating a report for future consumption). This style of communication is usually event-based and relies on message queuing. Its main advantages are that it improves decoupling between microservices and by handling work asynchronously, can improve response latency in certain scenarios.

This is a great write-up on the subject: https://www.obsessedcoder.com/blog/posts/26d7d0acade24aafb4f6d27cef10e948/styles-of-communication-between-microservices-in-azure

The example mentions using Azure ServiceBus but really could apply to any eventing technology.