Есть например сайт типа Кинопоиска. Там есть система биллинга, к которой

подключены разные интеграции (apple, google, оплата по карте).
Система, которая отвечает за список контента.

Как такое через микросервисы представить?

Допустим, разобьем на биллинг, интеграции и контент.

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

Для этого потребуется довольно сложная система синхронизации, которая бы учитывала отказ на каждом шагу.

У меня не хватит экспертизы в этой области чтобы выделить связные контекст к сожалению

Там можно выделить агрегаты, но придется их все трогать в процессе заказа

Да в этом кейсе без распределенной транзакции не обойтись, хотя по сути можно развязать логику на уровне интерфейса (топорно), чтобы он ходил в разные сервисы на бэке

Тогда клиент будет ответственный за консистентность

В вашем кейсе есть разные типы данных, к которым применимы разные гарантии консистентности Строгая консистентность вам требуется только в том месте, где с пользователя непосредственно списывают деньги, то есть сам биллинг, который дергает интеграции (при этом сами интеграции вам выдадут все механизмы, чтобы точно определить текущее состояние денежной транзакции в любой момент времени) Информация об открытом / закрытом контенте для пользователя по сути не затрагивает деньги, а значит ничего страшного, если мы там получим eventual консистентность (+- секунда в отображении оплаченного контента роли не играет, деньги то уже получили :))

Так нужна система которая гарантированно откроет контент, я не против eventual consistency

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

Слишком общие слова

ну какой пример такие и слова, в вашем примере вообще ничего сложного нет:)

Это только на первый взгляд

Ну везде есть подводные камни, просто есть целые классы задач на порядок сложнее

Например?

Задачи где реально требуется распределенная транзакция

Например если контент не получается открыть, нужно откатить оплату.

ну если только загонять открытие контента в одну транзакцию с оплатой и возвратом, по мне это выстрел себе в ногу)

Альтернатива это всякие компенсационные транзакции и прочие весёлости

А в чем принципиальное отличие от монолитной архитектуры? Вот у вас транзаха пошла, поехала оплата в банк, и прога упала(проц сгорел). Платеж ушел, транзаха незакоммичена