The best way to implement a distributed business transaction in a microservice environment is through an event-driven architecture, which we have explored a few times throughout this book so far.

If it is required to change the state of the system, the first service changes its data in its own database, and the same inner transaction publishes an event to a message broker. So, even if transactions are involved, they do not cross the boundary of the service. The second service, which registers the subscription to the required type of events, receives events and changes its storage accordingly, as well as possibly sending an event. The services are not blocked together and do not depend on each other; the only coupling present in the system is on the messages that they exchange. In contrast, with distributed transactions, the event-driven architecture allows a system to progress even if the second service is not running at the time when the first service acts. This characteristic is very important as it directly impacts the resilience of the system. A distributed transaction demands that all concerned components (microservices) have to be available and have to operate correctly during the whole duration of a transaction in order for it to progress. The more microservices a system has, or the broader the microservices' involvement during distributed transactions, the harder it is for the system to progress.

In the same way as before, when two services communicate a lot in a chatty fashion, they may be considered for merging. Also, adapter services making multiple updates to a few services may be implemented using events.