Synchronous communication between services in microservices with an example!


  • Communication strategies between services.
  • Full example with drawings for better clarification.
  • Advantages.
  • Disadvantages.
  • Example
  • Conclusion

There are two general strategies referred to as synchronous or sync and asynchronous or async.

I want you to understand right away that in the microservices world these terms do not mean what they mean in the JavaScript world.

So JavaScript has its own definition of sync and async.

That is not the same thing as sync and async in microservices, very different terms.

So now let’s talk first about synchronous communication style.

Services communicate with each other using direct requests, in which communication happens in real-time.

So we’re going to apply this idea of synchronous communication to the example that we were looking at above

Let’s imagine this e-commerce application where we’ve got users, products, and orders.

So if we were going to use synchronous communication, we can imagine that a request might come into service (D) And it might say, Show me all the products that have been ordered by the user with ID number one,

the first thing that Service (D) might do is make a direct request over to service (A), which might be a plain HTTP request, It might exchange JSON whatever its form is. It is a direct request from service (D) over to service (A), service (D) would then check to make sure that maybe that user exists.

It would then get a response back and if that user exists, it might then make a follow-up request over to service (C) and find all the orders that have been created for this user.

It would get back a response and then finally make a request over to Service (B) and say, Give me details about these particular products.

So after making those three different requests service (D) would then have all the information it needs to respond to the overall request.

At no point in time did service (D) reach directly into any of these databases over here.

So we have not violated any big rules around our database per service pattern.

There are some definite advantages and disadvantages to this approach.

So let’s take a look at those right away.

  • Conceptually easy to understand!
  • Service (D) won’t need a database.
  • Introduce a dependency between services.
    That means that if any of these services go down for any reason, like, let’s say, service (A) if that goes down right there now all of a sudden Service D is not going to work correctly either. So service (D) is going to fail entirely as well, Which means that we might lose the functionality of big pieces of our application at some point in time if some key critical service starts to go down.
  • If any inter-service request fails, the overall request fails
    So very similar to what we just said about service failing. If for some reason this request right here fails. so now we don’t know if that user exists, so chances are we would throw an error and respond to the request and say sorry, but an error occurred. Can’t help you 🥲.
  • entire request only as fast as the slowest request.
    let’s imagine that the first request (1) takes 10ms, the second request (2) take also 10ms, and the third request (final request) for a craze reason takes 20s, so that means that overall, we’re going to have 10ms + 10ms + 20s = 20s and 20ms, So we’re only ever going to be as fast as the slowest request.

as we know with synchronous communication, the caller sends a message and waits for the receiver to respond. This is appropriate for actions such as login and purchase, in which the caller must have a reply.

also, phone calls or video meetings consider synchronous communication.

You learned what synchronous communication looks like and that will help you to decide when to use it, in the next article will know what’s asynchronous communication and its advantages & disadvantages.

And that brings us to the end! Thank you so much for reading through this.

Let’s connect on LinkedIn, Twitter



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Software engineer, Problem solver, Geek.