Transactions

Each microservice can use a database of its choice. The chosen databases may or may not have the ACID property (https://en.wikipedia.org/wiki/ACID) and support transactions. This is one of the reasons why distributed transactions are hard to implement with microservices. However, business transactions involving changes across multiple business entities cannot be omitted entirely, and therefore microservices implement distributed transactions by using data workflows, as shown in the following diagram:

Microservices publish events whenever they make a change to the database. The events contain the type of change along with immutable data about the business entities that were affected by this change. Other services then listen to these events asynchronously and perform the changes strictly in the order in which events were published. A single transaction may contain one or more events that may result in cascading events generated by the microservices that are affected by it. Due to the asynchronous nature of the event flow, the consistency achieved across microservices in this case is eventual (https://en.wikipedia.org/wiki/Eventual_consistency).

If a transaction fails, the service that encounters the failure generates compensatory events to nullify the changes made across microservices that have already processed the transaction events in the chain. The compensatory events flow backwards towards the origin of the transaction, as shown in the preceding diagram. Compensatory events are idempotent in nature and retried until they succeed.