Transactional workflows in a microservices architecture on google cloud

we recommend that you implement a transactional workflow in your microservices architecture.

This document describes two patterns that you can use to implement a transactional workflow in a microservices architecture. The patterns are as follows:

• Choreography-based saga
• Synchronous orchestration

In a choreography-based saga microservices pattern, microservices work as an autonomous-distributed system. When a service changes the status of its own entity, it publishes an event to notify other services of updates. The notification event triggers other services to act. In this way, multiple services work together to complete a transactional process. The communication between microservices is asynchronous. When a service publishes an event, no information is sent to the publishing service to confirm the services that receive the event, or when they receive it.

When a microservice modifies its own data in the database and publishes an event to notify the database, these two operations must be conducted in an atomic way. For example, if the microservice fails after modifying data without publishing an event, the transactional process stops. In this case, the data can potentially be left in an inconsistent state across the multiple microservices that are involved in the transaction.

If the event-publisher service fails after publishing an event without changing the published column, the service publishes the same event again after it recovers. Because the republication of the event causes a duplicate event, the microservices that receive the event must check for potential duplication and handle it accordingly. This approach helps to guarantee the idempotence of the event handling.

In the example application, before you process a message, you can use Datastore to check if it's duplicated. This approach means that the service which consumes the messages (Customer Service, in this case) is idempotent. This approach is commonly called the "idempotent consumer" pattern. Some frameworks implement this pattern as a built-in feature—for example, Eventuate.

When you consider whether to implement a choreography-based saga or synchronous orchestration, the best choice for your organization is always the pattern which is most suitable for its needs. However, in general, because of the simplicity of its design, synchronous orchestration is often the first choice for many enterprises.