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

В традиционной системе с одной базой данных (монолите) управление транзакциями относительно просто. Но что, если сервис бронирования авиабилетов и сервис бронирования отелей — это две совершенно разные системы со своими собственными базами данных? В таком случае одна операция пользователя охватывает несколько независимых систем. Это и есть распределённая транзакция.

Необходимость в них резко возросла с появлением микросервисной архитектуры. Вместо одного большого приложения компании создают множество небольших, независимых сервисов, каждый из которых отвечает за свою часть бизнес-логики. Например, в интернет-магазине оформление заказа может включать:

• Сервис заказов: создание нового заказа.
• Сервис инвентаризации: уменьшение количества товара на складе.
• Платёжный сервис: обработка платежа.
• Сервис доставки: создание заявки на отгрузку.

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

Обеспечить свойства ACID (атомарность, согласованность, изоляция, долговечность) для транзакции в одной базе данных — задача решённая. Но распространение этих гарантий на несколько систем порождает серьёзные проблемы.

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

Согласованность. Поддержание согласованности данных ещё сложнее. В распределённой системе не существует единого момента времени. Из-за сетевых задержек изменения в одной базе данных могут стать видимыми раньше, чем в другой. Это создаёт риск того, что разные части системы будут работать с устаревшими данными.

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

Сбои. Распределённые системы по своей природе подвержены частичным сбоям. Может отказать отдельный сервис, база данных или сетевое соединение между ними. Система должна быть спроектирована так, чтобы корректно обрабатывать такие сбои, не нарушая целостности данных. Что делать, если координатор транзакции выходит из строя после того, как отправил команду на фиксацию некоторым, но не всем участникам?

Эти вызовы привели к разработке специальных протоколов, таких как двухфазная фиксация (2PC), и архитектурных паттернов, например, саги, которые предлагают компромиссы для управления распределёнными транзакциями.