Let's look back for a second and analyze what functions distributed transactions play in a software system. It is evident that we use distributed transactions to be sure about the system state, or in other words, we eliminate the uncertainty that some state across the system may be inconsistent. However, this elimination of uncertainty is a very restrictive demand. Vaughn Vernon, the author of Implementing Domain-Driven Design, proposes to embed uncertainty into the domain model. According to him, if it is tough to protect the system from inconsistent state and inconsistency still occurs no matter how hard we fight against it, it may be beneficial to accept the uncertainty and embed it as part of a regular business workflow.

For example, our system may still create an order without verified payment information by introducing a new state called verifying payment info. This new event converts an uncertain situation (payment information may be valid or invalid) into a separate business step that may be occupied for a finite time (until payment information is validated). With this approach, we do not require our system to be consistent all of the time. Instead, it is required to ensure that the system has a consistent vision about the state of each business transaction. Such future consistency is called eventual consistency. The following diagram depicts this:

Usually, eventual consistency guarantees are enough to build a sound system that successfully progresses its operation. Moreover, any distributed system has to deal with eventual consistency in order to be available (processing user requests) and to be partition tolerant (survive network outages between components).