Building CQRS systems is one approach to realizing asynchronous, eventually consistent communication. As we have seen previously in this book, there are many forms of communication, synchronous as well as asynchronous.

In order to enable scalable applications, distributed systems should not rely on synchronous communication that involves several systems. This leads to distributed transactions.

One approach to realize scalability with technology-agnostic, synchronous communication protocols is to model logically asynchronous processes. For example, communication protocols such as HTTP can be used to trigger processing that happens asynchronously while the caller immediately returns. This introduces eventual consistency, but enables the system to scale.

This also involves the consideration of whether the applications that made the distributed system make a difference in system-internal, and external communication. CQRS uses this approach by offering external interfaces, for example, using HTTP, to the clients, whereas the services themselves communicate via the event store. Modeling asynchronous processes that are accessed via uniform protocol doesn't distinguish here.

In general, it's advisable to prefer availability, that is, scalability, over consistency when designing distributed systems. There are many approaches possible, CQRS is one of them, combining asynchronous communication with event sourcing.

The following section covers the necessity of self-sufficient applications.