รูปแบบ Saga สำหรับธุรกรรมแบบกระจาย

In event-driven systems each service owns its own data. A single business operation may span several services, but there is no shared transaction to roll them all back.

A saga breaks one big transaction into a sequence of local transactions. If a step fails, earlier steps are undone with compensating actions.

Placing an order: reserve inventory, charge payment, create shipment. If payment fails, you must release the reserved inventory.

Every forward step needs a matching undo. Reserve has Release; Charge has Refund. Compensations make the system eventually consistent.

In choreography, each service reacts to events and emits the next event. There is no central coordinator, but the flow is implicit and harder to follow.

In orchestration, a coordinator (often AWS Step Functions) explicitly drives each step and triggers compensations on failure. The flow is centralized and visible.

Step Functions supports a Catch on each task to invoke a compensation, making it a natural home for orchestrated sagas.

Saga steps and compensations may be retried, so each must be idempotent. Use a unique transaction id to detect and ignore duplicates.

During a saga the system is temporarily inconsistent. Design the UI and downstream consumers to tolerate states like "payment pending".

To avoid conflicts mid-saga, mark records with a pending status (a semantic lock) so other operations know the data is in flight.

Use sagas when a workflow truly spans services. If everything lives in one service or one database, a normal local transaction is simpler and safer.

Test your saga knowledge.

You learned the saga pattern: split a distributed operation into local steps with compensating undos, choose choreography or orchestration, and keep steps idempotent.