Why it matters

Sagas make long-running distributed operations tractable. Without them, you'd either use 2PC (blocking, slow) or accept inconsistency (bad UX). Sagas are the middle path.

Advertisement

The architecture

Choreography: services react to events and emit new events. No central coordinator. Simpler to start, harder to reason about at scale.

Orchestration: central saga orchestrator explicitly calls each service in sequence. Easier to reason about, but orchestrator is critical component.

Saga steps + compensationsStep 1: reserve seatcompensate: cancelStep 2: charge cardcompensate: refundStep 3: send ticketcompensate: voidIf step 3 fails, run compensations for steps 1 and 2 to reach clean state
Saga sequence and rollback.
Advertisement

How it works end to end

Compensating actions must be idempotent. Steps may be re-run after failures.

Compensations aren't rollbacks in the DB sense — they're semantic reversals. A refund isn't the same as un-doing a charge.

Semantic side effects (email sent, physical item shipped) can't be truly undone. Design sagas to catch failures before those steps.