Saga Pattern

В традиционных монолитных приложениях поддерживать согласованность данных между несколькими объектами не составляет труда. Ядра реляционных баз данных предоставляют гарантии ACID (атомарность, согласованность, изоляция, долговечность), заключенные в локальные транзакции SQL. Если размещение заказа, удержание платежа или резервирование запасов завершаются неудачей на полпути, вызов ROLLBACK мгновенно отменяет все изменения в базе данных. Однако при переходе на современную архитектуру микросервисов управление данными существенно меняется. Чтобы обеспечить автономию домена и независимую масштабируемость, каждый микросервис владеет собственной базой данных. Одна бизнес-операция, такая как обработка заказа электронной коммерции, теперь охватывает несколько границ служб и механизмов баз данных (например, PostgreSQL для заказов, DynamoDB для платежей, Redis для инвентаризации).

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