Microservice Communications between Backend Internal Microservices

In this article, we are going to discuss Microservices Service-to-Service Communications between Backend Internal Microservices. As you know that we learned practices and patterns about Microservices Communications Design patterns and add them into our design toolbox. And we will use these pattern and practices when designing microservice architecture.

By the end of the article, you will learn how to communicate Microservices between Backend Internal Microservices with applying Microservices Communications Design patterns and principles.

Step by Step Design Architectures w/ Course

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.

Microservice Communications between Backend Internal Microservices

In the last articles, we have created API Gateways in our microservices architecture. And said that all these sync request comes from the clients and goes to internal microservices over the API Gateways.

But what if the client requests are required to visit more than one internal microservices ? How we can manage internal microservice communications ?

When designing microservices applications, we should careful about that how back-end internal microservices communicate with each other. The best practice is reducing inter-service communication as much as possible. However, In some cases, we can’t reduce these internal communications due to customer requirement or the requested operation need to visit several internal services.

Mostly this is happened when the client send query request to internal microservices, in order to accumulate some data in the screen page of frontend application.

For example, look at the above image, and think about the use case like;

  • User wants to see shopping cart with details of product and price information’s.

So How we can implement this request ?

There are many approaches for implementing this kind of query operations.
But for now we are focus on; sync communication over the API Gateways which is the Request/Response Messaging.

So for our case, basically the client send http request to the microservices for querying Shopping Cart information.

If we follow the request,
1- The client send request to API Gateway
2- API Gateway dispatch request to SC
3- SC need to extend information by sending sync request to Product and Pricing microservices in order to get product and price details.

So these internal calls makes coupling each microservices, in our case Shopping CartProduct and Pricing microservices are dependent and coupling each other. And if one of the microservices is down, it can’t return data to the client so its not any fault-tolerance. If dependency and coupling of microservices are increase, then it makes lots of problems and loose the microservices architecture power.

In this case there is only 2 internal calls so it can be manageable and it might be acceptable for some systems. However, if the required service calls are much then a few HTTP calls to multiple microservices, than the project goes to can’t manageable situation.

See the picture.

And think about that we have a use case that is place order. If the client checkout shopping cart, this will start a set of operations. So if we try to perform this place order use case with Request/Response sync Messaging pattern, than it will seems like as this image.

As you can see that there is 6 sync http request for one client http request. So it is obvious that increase latency and negatively impact the performance, scalability, and availability of our system.

If we have this of use case, what if the step 5 or 6 is failed, or what if some middle service are down ? Even if there is no down, it could be busy of some services that can’t response in a time manner and that caused not acceptable high latencies.

So what could be the solution of this kind of requirements ?

We can apply 2 way to solve this issues,
1- Change microservices communications to async way with message broker systems, we will see this in the next section.
2- using Service Aggregator Pattern to aggregate some query operations in 1 API Gateway.

So we should evolve our architecture with applying Async communication or Service Aggregator Pattern in microservices patterns in order to accommodate business adaptations faster time-to-market and handle larger requests.

Step by Step Design Architectures w/ Course

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.

--

--

Design microservice systems using the right architecture design patterns and techniques. Handle millions of request with designing system for high availability, high scalability, low latency, and resilience to network failures on microservices distributed architectures.

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
Mehmet Ozkaya

Software/Solutions Architect, Udemy Instructor, Working on Cloud-Native and Serverless Event-driven Microservices Architectures https://github.com/mehmetozkaya