An official course for ODC mentions the Saga pattern.

A sample of distributed transaction in which a user interface app orchestrates three Service Actions in different apps.
When the last Service Action ends up in an error state, one previous transaction is compensated.
The word "compensate" should mean compensate transaction, but it is used without an explanation in the video.

Some ways to handle inconsistent transactions:

retry
Fallback should exist like a Timer that runs periodically to compensate
notify a back office to manually compensate

Junji Watanabe

We can make use of BPT to implement the Saga pattern.

Junji Watanabe

From the book "Microservices Patterns: With examples in Java."

Chapter 4. Managing transactions with sagas

an operation that spans services must use what's known as a saga, a message-driven sequence of local transactions, to maintain data consistency.

Is it necessary to use messages to realize transactions between services? Maybe we can implement it by

using Server/Service Action to call multiple services and handle transactions among them
using BPT Process like message brokers
using a real Message Broker

(In the same section)

An important benefit of asynchronous messaging is that it ensures that all the steps of a saga are executed, even if one of more of the saga's participants is temporarily unavailable.

So, if we adopt a non-messaging architecture and when trying to do a compensating transaction and the service is unavailable, there will be an unfinished compensating transaction. Messaging may solve that kind of problems.

Junji Watanabe

To prevent lost transactions, we need to track which transactions to be compensated for and have a way to retry them.

One more merit of using messaging when implementing Sagas is that the saga participants are loosely coupled.

Junji Watanabe

In the case of an error, Saga must publish compensation transactions in the reverse order.

compensatable transaction
pivot transaction

Junji Watanabe

The types of Saga

Choreography

Distribute the decision making and sequencing the saga participants. They primarily communicate by exchanging events.
... the saga participants subscribe to each other's events and respond accordingly.
... can work well for simple sagas

Orchestration

Centralize a saga's coordination logic in a saga orchestrator class. A saga orchestrator sends command messages to saga participants telling them which operations to perform.
When using orchestration, you define an orchestrator class whose sole responsibility is to tell the saga participants what to do. The saga orchestrator communicates with the participants using command/async reply-style.
Orchestration also has a drawback: the risk of centralizing too much business logic in the orchestrator

countermeasures

Junji Watanabe

I attended Developer Day Tokyo on April 26, 2024, and saw a session referring to an Orchestration Saga with Event implementation.