Edition 0 Updated to asp. Net core 0

Asynchronous microservice integration enforces microservice’s 
autonomy 
As mentioned, the important point when building a microservices-based application is the way you 
integrate your microservices. Ideally, you should try to minimize the communication between the 
internal microservices. The fewer communications between microservices, the better. But in many 
cases, you’ll have to somehow integrate the microservices. When you need to do that, the critical rule 
here is that the communic
ation between the microservices should be asynchronous. That doesn’t 
mean that you have to use a specific protocol (for example, asynchronous messaging versus 
synchronous HTTP). It just means that the communication between microservices should be done only 
by propagating data asynchronously, but try not to depend on other internal microservices as part of 
the initial service’s HTTP request/response operation.
If possible, never depend on synchronous communication (request/response) between multiple 
microservices, not even for queries. The goal of each microservice is to be autonomous and available 
to the client consumer, even if the other services that are part of the end-to-end application are down 
or unhealthy. If you think you need to make a call from one microservice to other microservices (like 
performing an HTTP request for a data query) to be able to provide a response to a client application, 
you have an architecture that won’t be resilient when some microservices fail.
Moreover, having HTTP dependencies between microservices, like when creating long 
request/response cycles with HTTP request chains, as shown in the first part of the Figure 4-15, not 
only makes your microservices not autonomous but also their performance is impacted as soon as 
one of th
e services in that chain isn’t performing well.
The more you add synchronous dependencies between microservices, such as query requests, the 
worse the overall response time gets for the client apps. 

---

51 
CHAPTER 3 | Architecting container and microservice-based applications 
Figure 4-15. Anti-patterns and patterns in communication between microservices 
As shown in the above diagram, in synchronous communication a “chain” of requests is created 
between microservices while serving the client request. This is an anti-pattern. In asynchronous 
communication microservices use asynchronous messages or http polling to communicate with other 
microservices, but the client request is served right away. 
If your microservice needs to raise an additional action in another microservice, if possible, do not 
perform that action synchronously and as part of the original microservice request and reply 
operation. Instead, do it asynchronously (using asynchronous messaging or integration events, 
queues, etc.). But, as much as possible, do not invoke the action synchronously as part of the original 
synchronous request and reply operation. 
And finally (and this is where most of the issues arise when building microservices), if your initial 
microservice needs data that’s originally owned by other microservices, do not rely on making 
synchronous requests for that data. Instead, replicate or propagate that data (only the attributes you 
need) into the initial service’s database by using eventual consistency (typically by using integration 
events, as explained in upcoming sections). 
As noted earlier in the 
Identifying domain-model boundaries for each microservice
 section, 
duplicating some data across several microservices isn’t an incorrect design—
on the contrary, when 
doing that you can translate the data into the specific language or terms of that additional domain or 
Bounded Context. For instance, in the 
eShopOnContainers application
 you have a microservice named 
identity-api
that’s in charge of most of the user’s data with an entity named 
User
. However, when 
you need to store data about the user within the 
Ordering
microservice, you store it as a different 
entity named 
Buyer
. The 
Buyer
entity shares the same identity with the original 
User
entity, but it 
might have only the few attributes needed by the 
Ordering
domain, and not the whole user profile. 

---

52 
CHAPTER 3 | Architecting container and microservice-based applications 
You might use any protocol to communicate and propagate data asynchronously across microservices 
in order to have eventual consistency. As mentioned, you could use integration events using an event 
bus or message broker or you could even use HTTP by polling the other services instead. It doesn’t 
matter. The important rule is to not create synchronous dependencies between your microservices. 
The following sections explain the multiple communication styles you can consider using in a 
microservice-based application.