Certainly it's necessary for distributed system to communicate. Since computer networks cannot be considered as reliable, even not in company-internal networks, reliable communication is a necessity. Business use cases are required to communicate in a reliable way, in order to ensure correct behavior.

Earlier in this book, we introduced the so-called CAP theorem that claims that it's impossible for distributed data stores to guarantee at most two of the three specified constraints. Systems can effectively choose whether they want to guarantee consistency or horizontal scalability. This highly affects the communication in a distributed world.

In general, enterprise systems should be consistent in their use cases. Business logic should transform the overall system from one consistent state to another, different consistent state.

In distributed systems, an overall consistent state would imply that use cases that communicate to external concerns would have to ensure that the invoked external logic also adheres to consistency. This approach leads to distributed transactions. Use cases that are invoked on a system would execute in an all-or-nothing fashion, including all external systems. This implies a need for a lock on all involved, distributed functionality until every single distributed application successfully performed its responsibilities.

Naturally, this approach doesn't scale. The fact that the system is distributed requires this transaction orchestration to be performed over the potentially slow network. This introduces a bottleneck, which results in a locking situation, since involved applications have to block and wait a relatively large amount of time.

Generally speaking, synchronous, consistent communication is only advisable for applications that don't involve more than two applications at a time. Performance tests as well as production experience indicate whether a chosen communication scenario scales well enough for the given use case and environment.

Using asynchronous communication is motivated by scalability. Distributed systems that communicate asynchronously won't, by definition, be consistent at all times. Asynchronous communication can happen on a logical level, where synchronous calls only initiate business logic without awaiting a consistent result.

Let's have a look into the motivations and design behind asynchronous, eventually consistent communication in distributed applications.