saga-orchestration

Distributed transaction rollback for partially failed microservices workflows is handled by coordinating saga steps and executing compensating actions in reverse order for any completed work, ensuring consistent system state across service boundaries.

Saga orchestration centrally coordinates step dispatch and compensations, whereas choreography uses event-driven reactions. Orchestration is preferred for complex workflows needing strict ordering, audit trails, durable replay, and human intervention states.

Design a saga for order fulfillment and payment pipelines by persisting step state, dispatching commands to each service, and running reverse-order compensations for long-running business workflows if any later step fails.

Yes, idempotent step execution keyed by saga_id and step_name is required for saga orchestration. It ensures safe replay recovery during workflow recovery when per-step timeouts trigger retries across distributed systems.

When a compensation action fails during a multi-step rollback, the saga orchestration explicitly handles the failure through retry mechanisms, routes the event to a dead letter queue, and enters an operator intervention state.

You should not use saga orchestration when your distributed workflows lack durable persistence requirements, have very few steps without strict ordering needs, or do not require audit trails and replay recovery for fault tolerance.