☀Объяснение:

Двухфазная фиксация (2PC):
Протокол, обеспечивающий строгую атомарность в распределённой среде. Имеет две фазы:
Подготовка (prepare) – координатор опрашивает все узлы, могут ли они зафиксировать транзакцию; узлы блокируют ресурсы и отвечают «готов».
Фиксация (commit) – если все готовы, координатор даёт команду commit, иначе – rollback.

Недостатки 2PC, критичные для требований:
Блокировки – ресурсы заблокированы на всё время транзакции (включая ожидание ответов). Это увеличивает задержку.
Координатор – единая точка отказа – если координатор упал после отправки commit, система может зависнуть.
Плохая масштабируемость – при большом числе участников растёт время и вероятность сбоев.
Не подходит для высокодоступных систем – требование «высокая доступность» несовместимо с 2PC, так как при сетевом разделении 2PC блокируется.

Saga (Сага):
Разбивает распределённую транзакцию на последовательность локальных транзакций. Каждая локальная транзакция обновляет свой сервис и публикует событие. Если транзакция не удалась, запускаются компенсирующие транзакции (откат выполненных шагов).

Варианты реализации Saga:
Хореография – сервисы обмениваются событиями без центрального координатора.
Оркестрация – центральный оркестратор управляет шагами и компенсациями.

Преимущества Saga:
Нет длительных блокировок – каждая локальная транзакция быстро фиксирует изменения.
Высокая доступность – нет единой точки отказа (в хореографии). Даже при оркестрации можно перезапустить оркестратор.

Масштабируемость – каждый сервис может обрабатывать свои транзакции независимо.
Недостаток Saga:
Конечная согласованность (eventual consistency) – в момент между шагами данные могут быть несогласованы (например, деньги списаны, товар ещё не зарезервирован). Но для многих бизнес-сценариев это допустимо.

Почему Saga подходит под требования «низкая задержка, высокая доступность»:
Нет блокировок → низкая задержка.
Нет единой точки отказа → высокая доступность.
Компенсации позволяют откатить изменения без глобальных блокировок.

Реальный пример:
В Uber для заказа поездки используется Saga: создание заказа → поиск водителя → списание средств → уведомление. Если поиск водителя не удался, запускается компенсация: отмена заказа и возврат средств.

Что должен зафиксировать аналитик:
«Для критичных по доступности и латентности распределённых операций использовать паттерн Saga».
«Для каждого шага определить компенсирующее действие (что делать при отказе)».
«Допустима конечная согласованность с максимальным окном 5 секунд».

Вывод: 2PC подходит для систем, где строгая атомарность важнее доступности и задержки (например, банковский перевод внутри одного кластера). Для микросервисов с высокими требованиями к доступности и скорости Saga – стандарт.