В монолите на WooCommerce создание заказа и списание товара проходят в рамках одной ACID-транзакции с жёстким откатом, что упрощает разработку, но ограничивает масштабирование. В облачной архитектуре Яндекс Облака с микросервисами консистентность достигается через сагу и компенсирующие транзакции в Yandex Workflows — это сложнее, зато позволяет гибко масштабировать отдельные домены и обрабатывать длительные операции.
Контекст
Возьмём один сценарий и прогоним его через две системы.
Сценарий: покупатель нажимает «Оформить заказ». Система должна создать заказ, зарезервировать товар, принять оплату и отправить подтверждение — четыре шага, и каждый может упасть.
Система А — модульный монолит на WooCommerce. Весь код и вся база в одном месте: заказ, остатки и платёж лежат рядом и меняются в рамках одной транзакции.
Система Б — набор сервисов в Яндекс Облаке. Те же четыре шага разложены по отдельным сервисам — Order, Inventory, Payment, Notification. У каждого своя база, общаются они по сети.
Разница между ними проявляется в момент сбоя — на нём и построен дальнейший разбор.
Вариант 1. Модульный монолит (WooCommerce / WordPress)
Вся логика выполняется в одном процессе и одной базе — обычно MySQL или MariaDB.
Транзакция при создании заказа:
Начало транзакции (BEGIN)
├── Создаём заказ (orders)
├── Резервируем/списываем товары (stock)
├── Создаём платёжную запись (payments)
├── Пишем в очередь задач (Action Scheduler)
└── Коммитим (COMMIT)
При ошибке на любом шаге выполняется ROLLBACK, и изменения применяются атомарно — это классический ACID.
После коммита побочные действия идут асинхронно:
- отправка письма через Action Scheduler или WP Background Processing;
- уведомление в Telegram или Slack;
- синхронизация с 1С и CRM;
- генерация документов.
Преимущества:
- простые рассуждения: заказ создаётся целиком или не создаётся вовсе;
- лёгкий откат изменений;
- минимум распределённых проблем;
- консистентность между заказом, остатками и платежом поддерживается штатно.
Ограничения:
- всё завязано на одну базу и один рантайм;
- при росте нагрузки отдельные части — платежи, склад, уведомления — масштабировать сложнее;
- долгие внешние вызовы (платёжный шлюз, 1С) приходится выносить в очередь, иначе транзакция остаётся открытой.
В WooCommerce процесс обычно выглядит так:
- Покупатель нажимает «Оплатить».
- В транзакции создаётся заказ в статусе
pendingилиon-hold. - Вызывается платёжный шлюз — уже вне транзакции или с коротким таймаутом.
- По вебхуку обновляется статус заказа и запускаются фоновые задачи.
Вариант 2. Мультисервисная архитектура (Яндекс Облако)
Логика разделена между сервисами: Order Service, Inventory Service, Payment Service, Notification Service и другими. У каждого своя база, общей ACID-транзакции между ними нет.
Как обеспечивается консистентность
Основной паттерн — сага: последовательность локальных транзакций, в которой сбой шага запускает компенсирующие действия. Сагу строят двумя способами: хореографией, когда сервисы реагируют на события друг друга, или оркестрацией, когда процессом управляет отдельный координатор.
На Яндекс Облаке оркестрацию удобно реализовать через Yandex Workflows — движок долгоживущих процессов (durable execution). Он хранит состояние процесса и берёт на себя ожидание, повторные попытки и запуск компенсаций.
Сценарий «Создание заказа»:
# Упрощённо
1. Создать заказ (Order Service) → статус "Created"
2. Зарезервировать товар (Inventory Service)
├── Успех → идём дальше
└── Неудача → компенсируем: отменяем заказ
3. Создать платёж (Payment Service)
├── Успех → подтверждаем резерв + переводим заказ в "Paid"
└── Неудача / таймаут → компенсируем:
- отменяем платёж (если создался)
- снимаем резерв
- отменяем заказ
4. Отправить уведомления (асинхронно)
Сравнение вариантов
| Аспект | Модульный монолит (WooCommerce) | Мультисервисы + Yandex Workflows |
| Атомарность | ACID-транзакция | Сага и компенсации |
| Откат | `ROLLBACK` | Компенсирующие транзакции |
| Долгие операции | Выносятся в очередь | Workflow ждёт и повторяет попытки сам |
| Консистентность | Строгая | В конечном счёте (eventual) |
| Сложность | Низкая или средняя | Высокая |
| Масштабирование | Вертикальное плюс очередь | Горизонтальное по сервисам |
Практические следствия
В монолите:
- заказ, остатки и платёж допустимо держать в одной транзакции;
- очередь нужна в основном для побочных эффектов — почты, вебхуков, интеграций;
- ошибки обрабатываются через
try/catchи откат.
В микросервисах:
- компенсации проектируются явно;
- нужно определить поведение при частичном выполнении — например, деньги списаны, а товар закончился;
- почти все операции должны быть идемпотентными;
- Workflows, Temporal, Cadence или Step Functions берут на себя персистентность состояния, ретраи, таймауты и версионирование процессов.
Выводы
Монолит подходит при умеренной нагрузке, небольшой команде и не слишком сложной бизнес-логике, когда приоритет — скорость разработки и простота системы.
Мультисервисы оправданы, когда части системы масштабируются независимо, есть жёсткие требования к доступности отдельных доменов, команда достаточно велика для распределённой сложности и появляются длительные бизнес-процессы: рассрочка, сложные согласования, мультискладовые сценарии.
| Критерий | Монолит | Мультисервисы |
| Нагрузка | Умеренная, растёт постепенно | Высокая, неравномерная по доменам |
| Команда | Небольшая, одна | Несколько автономных команд |
| Бизнес-логика | Линейная, в одном домене | Много доменов и длинных процессов |
| Требования к отказоустойчивости | Общие для приложения | Разные для каждого домена |