Какую проблему мы решаем
В бизнес-процессе часто есть несколько изменений, которые должны восприниматься как одно действие. Например, нельзя успешно уменьшить остаток и забыть записать саму операцию.
Если часть изменений применится, а часть нет, система окажется в состоянии, которое технически существует, но бизнес-смысла не имеет.
Как работают ACID-транзакции
ACID описывает четыре свойства транзакции: атомарность, согласованность, изоляцию и долговечность. В практическом смысле это означает, что группа изменений либо фиксируется как единое целое, либо откатывается, а параллельные операции не должны произвольно разрушать правила данных.
Внутри одной базы данных это обычно естественный и мощный инструмент. Чем больше систем мы пытаемся включить в одну общую транзакцию, тем сложнее координация, восстановление и доступность.
Что получает бизнес
Главный эффект — защита критических инвариантов. Там, где ошибка означает деньги, двойную продажу, неправильный остаток или юридически неверное состояние, строгая транзакционная граница резко снижает риск.
Транзакция также упрощает рассуждение о процессе: бизнес может считать несколько технических записей одним логическим действием.
Что получает команда
Команда получает простой механизм для локальной целостности: commit, rollback, уровни изоляции и понятную модель конкурирующих изменений.
Одновременно появляются требования к длительности транзакций, блокировкам, дедлокам и выбору уровня изоляции. Слишком широкая транзакция может сама стать источником задержек и отказов.
Что получает клиент
Клиент реже сталкивается с состояниями вроде «деньги списались, а заказ не появился» или «товар продали двум людям одновременно».
Для него это выглядит не как ACID, а как предсказуемость: операция либо состоялась, либо нет.
Чем мы за это платим
Строгая координация ограничивает параллелизм и может увеличивать latency. Чем выше уровень изоляции, тем больше операций вынуждены ждать друг друга.
Попытка сделать одну транзакцию через несколько сервисов особенно дорога: сеть падает, участники отвечают с разной скоростью, а блокировки и координация начинают влиять на доступность всего процесса.
Когда не нужно
Не каждый бизнес-процесс требует мгновенной глобальной согласованности. Для уведомлений, аналитики, поискового индекса или части межсервисных процессов eventual consistency часто дешевле и достаточно надёжна.
Если компенсация допустима, Saga может оказаться лучше распределённой транзакции.
Что стоит спросить перед решением
- Какие бизнес-инварианты нельзя нарушать даже временно?
- Можно ли удержать транзакцию внутри одной базы или одного сервиса?
- Что произойдёт при параллельных изменениях одних и тех же данных?
- Допустима ли компенсация вместо мгновенного rollback?
- Какой уровень изоляции действительно нужен, а не просто кажется безопаснее?
В итоге
ACID — не универсальный признак «правильной» архитектуры. Это сильная гарантия для тех границ, где бизнес действительно не может позволить себе промежуточное неверное состояние.
Лучше сделать маленькую транзакционную границу очень надёжной, чем пытаться заставить весь распределённый бизнес-процесс вести себя как одна база данных.