Networks are fundamentally unreliable: they function normally most of the time, but when they fail, they fail in a variety of unpredictable and undesirable ways. There are books on the subject of distributed system architecture. TL;DR: It's difficult and azure certification.

Many new microservices adopters tend to overlook such complexities. The most common method of connecting microservices is REST over HTTP(S). It makes the system brittle, just like any other synchronous communication protocol.

Consider what happens when a service becomes temporarily unhealthy: perhaps its database goes down, it struggles to keep up with the request load, or a new version of the service is deployed. All requests to the problematic service begin to fail — or Worse, you'll become extremely slow. The dependent service waits for the response and, as a result, blocks all incoming requests. The error spreads quickly upstream, causing cascading failures all over the place.

While HTTP communication cascading failures can be mitigated with patterns such as a circuit breaker and graceful degradation, a better solution is to make asynchronous communication the default. As an intermediary, a persistent queueing service is used.
Event-Driven application architecture refers to a style of application architecture that is based on sending events between services. When a service performs a useful action, it publishes an event — a record of what happened in its business domain. Another service monitors the published events and takes appropriate action.

Ankitagarg:
Networks are fundamentally unreliable: they function normally most of the time, but when they fail, they fail in a variety of unpredictable and undesirable ways. There are books on the subject of distributed system architecture. TL;DR: It's difficult and azure certification.

Many new microservices adopters tend to overlook such complexities. The most common method of connecting microservices is REST over HTTP(S). It makes the system brittle, just like any other synchronous communication protocol.

Consider what happens when a service becomes temporarily unhealthy: perhaps its database goes down, it struggles to keep up with the request load, or a new version of the service is deployed. All requests to the problematic service begin to fail — or Worse, you'll become extremely slow. The dependent service waits for the response and, as a result, blocks all incoming requests. The error spreads quickly upstream, causing cascading failures all over the place.

While HTTP communication cascading failures can be mitigated with patterns such as a circuit breaker and graceful degradation, a better solution is to make asynchronous communication the default. As an intermediary, a persistent queueing service is used.
Event-Driven application architecture refers to a style of application architecture that is based on sending events between services. When a service performs a useful action, it publishes an event — a record of what happened in its business domain. Another service monitors the published events and takes appropriate action.

Hmmmm nice article.
I am more interested in the asynchronous architecture.

Any resource that elaborate on it more?