Как реализуется паттерн Saga для управления распределенными транзакциями в микросервисной архитектуре?

Паттерн Saga используется для управления распределёнными транзакциями в микросервисной архитектуре, где традиционные транзакции ACID невозможны из-за распределённости данных и сервисов.

Идея в том, что большая бизнес-операция разбивается на серию локальных транзакций в разных сервисах. Каждая локальная транзакция сопровождается компенсирующей операцией, которая отменяет её эффект в случае ошибки на любом шаге.

Реализация в Go обычно строится вокруг оркестратора или хореографии:

• Оркестратор — централизованный сервис, который управляет последовательностью шагов и вызывает локальные транзакции, обрабатывает ошибки и запускает компенсирующие транзакции.
• Хореография — каждый сервис публикует события о выполнении шага, другие сервисы реагируют на них, выполняя свои шаги или компенсирующие действия.

Пример упрощённой оркестрации на Go:

func RunSaga() error {
    if err := ServiceA.DoStep(); err != nil {
        return err
    }
    if err := ServiceB.DoStep(); err != nil {
        ServiceA.Compensate() // откат первого шага
        return err
    }
    if err := ServiceC.DoStep(); err != nil {
        ServiceB.Compensate()
        ServiceA.Compensate()
        return err
    }
    return nil
}

В реальных системах используют очереди сообщений (Kafka, RabbitMQ) для передачи событий и управления состоянием саги, а также хранят состояние саги в базе для устойчивости к сбоям.