Архитектурные паттерны, позволяющие избавиться от необходимости атомарных транзакций между микросервисами, обычно основаны на асинхронной обработке и компенсационных механизмах. Один из таких паттернов — Saga.

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

Существует два основных вида Saga:

Choreography (Хореография)
- Каждый сервис публикует события и подписывается на события других сервисов.
- Нет центрального оркестратора, сервисы самостоятельно реагируют на события и запускают свои локальные транзакции.
- Пример: сервис A завершил операцию и опубликовал событие, сервис B, подписанный на это событие, запускает свою транзакцию.
Orchestration (Оркестрация)
- Центральный оркестратор управляет последовательностью вызовов микросервисов.
- Оркестратор вызывает сервисы по очереди и обрабатывает ошибки, инициируя компенсации при необходимости.

Разница:

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

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

func SagaOrchestrator() error {
    if err := ServiceA(); err != nil {
        return err
    }
    if err := ServiceB(); err != nil {
        compensateServiceA()
        return err
    }
    return nil
}

Таким образом, паттерн Saga позволяет обойтись без распределённых транзакций с атомарностью, используя локальные транзакции и компенсации.

Какие архитектурные паттерны позволяют избавиться от атомарности между микросервисами? Работала с паттерном Saga? Какие два вида Saga существуют и в чем разница?