saga pattern
When you can't use a single database transaction across services, model the workflow as a sequence of local steps, each with a compensating action that undoes it. If step 4 fails, run compensations for steps 1, 2, 3 in reverse to undo what already committed. Trades atomicity for liveness.
When you can't use a single database transaction across services, model the workflow as a sequence of local steps, each with a compensating action that undoes it. If step 4 fails, run compensations for steps 1, 2, 3 in reverse to undo what already committed. Trades atomicity for liveness.
symptoms
- need cross-service workflows but no distributed transaction
- inconsistent state when only some services succeeded
- manual cleanup of half-done workflows
causes
- microservice boundaries cutting through what was one transaction
- rejecting 2PC for performance / coupling reasons
fixes
- orchestration: central saga coordinator drives the steps
- choreography: services react to events, emit next
- idempotent compensations
- audit log of saga state for debugging
you might say
- saga
- compensating action
- undo step