Saga

When multiple services each own their own data, one business request often spans multiple stores. Trying to lock everything in one global transaction does not fit distributed systems well. But ignoring mid-flow failure leaves the system in an inconsistent state. Saga addresses that by replacing one giant transaction with a sequence of local transactions and compensating actions.

As service-owned data became common, traditional single-database transaction techniques no longer covered the whole business workflow. Yet the business still expected outcomes like an order flow to remain coherent end to end. Saga became a practical response to that pressure by treating distributed consistency as a managed sequence of local actions and compensations.

A saga executes steps such as create order, reserve stock, and charge payment in sequence. If each step succeeds, the workflow continues; if one fails, previously completed steps trigger compensation actions to restore a coherent overall outcome. The key is not pretending the workflow is instantly atomic, but explicitly designing the success path and the failure path together.

Saga and Circuit Breaker both deal with distributed failure, but Saga focuses on how a multi-step business workflow reaches a coherent result, while Circuit Breaker focuses on protecting the system from repeatedly failing remote calls. Saga is about business-flow consistency; Circuit Breaker is about call-path protection.

Saga is especially important in flows such as ordering, reservation, and settlement where multiple services participate and failures must be handled explicitly. The quality of a saga depends on how clearly each step, pivot, and compensation rule is defined. This is less about writing some glue code and more about designing the lifecycle of a distributed business process.