Edition 0 Updated to asp. Net core 0

Challenge #4: How to design communication across microservice 
boundaries 
Communicating across microservice boundaries is a real challenge. In this context, communication 
doesn’t refer to what protocol you should use (HTTP and REST, AMQP, messaging, and so on). Instead, 
it addresses what communication style you should use, and especially how coupled your 
microservices should be. Depending on the level of coupling, when failure occurs, the impact of that 
failure on your system will vary significantly. 
In a distributed system like a microservices-based application, with so many artifacts moving around 
and with distributed services across many servers or hosts, components will eventually fail. Partial 
failure and even larger outages will occur, so you need to design your microservices and the 
communication across them considering the common risks in this type of distributed system. 
A popular approach is to implement HTTP (REST)-based microservices, due to their simplicity. An 
HTTP-based approach is perfectly acceptable; the issue here is related to how you use it. If you use 
HTTP requests and responses just to interact with your microservices from client applications or from 
API Gateways, that’s fine. But if you create long chains of synchronous HTTP calls across microservices, 
communicating across their boundaries as if the microservices were objects in a monolithic 
application, your application will eventually run into problems. 
For instance, imagine that your client application makes an HTTP API call to an individual microservice 
like the Ordering microservice. If the Ordering microservice in turn calls additional microservices using 
HTTP within the same r
equest/response cycle, you’re creating a chain of HTTP calls. It might sound 
reasonable initially. However, there are important points to consider when going down this path: 
•
Blocking and low performance. Due to the synchronous nature of HTTP, the original request 
doesn’t get a response until all the internal HTTP calls are finished. Imagine if the number of 
these calls increases significantly and at the same time one of the intermediate HTTP calls to a 
microservice is blocked. The result is that performance is impacted, and the overall scalability will 
be exponentially affected as additional HTTP requests increase. 
•
Coupling microservices with HTTP. Business microservices shouldn’t be coupled with other 
business microservices. Ideally, they shouldn’t
“know” about the existence of other microservices. 
If your application relies on coupling microservices as in the example, achieving autonomy per 
microservice will be almost impossible. 
•
Failure in any one microservice. If you implemented a chain of microservices linked by HTTP 
calls, when any of the microservices fails (and eventually they will fail) the whole chain of 
microservices will fail. A microservice-based system should be designed to continue to work as 
well as possible during partial failures. Even if you implement client logic that uses retries with 
exponential backoff or circuit breaker mechanisms, the more complex the HTTP call chains are, 
the more complex it is to implement a failure strategy based on HTTP. 
In fact, if your internal microservices are communicating by creating chains of HTTP requests as 
described, it could be argued that you have a monolithic application, but one based on HTTP between 
processes instead of intra-process communication mechanisms. 

---

36 
CHAPTER 3 | Architecting container and microservice-based applications 
Therefore, in order to enforce microservice autonomy and have better resiliency, you should minimize 
the use of chains of request/response communication across microservices. It’s recommended that 
you use only asynchronous interaction for inter-microservice communication, either by using 
asynchronous message- and event-based communication, or by using (asynchronous) HTTP polling 
independently of the original HTTP request/response cycle. 
The use of asynchronous communication is explained with additional details later in this guide in the 
sections 
Asynchronous microservice integration enforces microservice’s autonomy
 and 
Asynchronous 
message-based communication
.