What problem does a saga solve?

Many business operations are pipelines : do A, then B, then C. In a single database you wrap that in one transaction—if B fails, A rolls back automatically. In the real world, A might be a room hold in a property system, B a card capture at a payment processor, and C an email via a provider. Those systems do not share one transaction log.

Without a structured approach you get ad hoc code: nested try / catch , manual “if payment failed, remember to release inventory” comments, and production bugs where orphan holds or double charges slip through when a step fails or times out.

A saga is a pattern for that situation:

You run the pipeline as a sequence of local steps (each step can succeed or fail on its own).

For steps that must be undone if a later step fails, you define an explicit compensating action —not a generic database rollback, but a business-meaningful reverse (release the hold, refund the charge).

A coordinator (here, SagaOrchestrator ) runs the forward steps in…