How do I handle partial failure across services?
Understand the concept
A cross-service workflow can partly succeed because each service commits independently. A saga coordinates local steps and compensating actions to recover when a later step fails. Compensation is a business recovery action, such as refunding a payment, and may not exactly erase every observable effect of the original action.
Important ideas
-
Use local transactions and durable workflow state.
-
A saga uses compensating actions when later steps fail; compensation is not always an exact undo.
-
Reconcile uncertain external results before repeating actions such as payments or notifications.
-
Persist workflow progress and support reconciliation when a timeout leaves a step's outcome uncertain.
Can you explain it without the notes?
How do I handle partial failure across services?
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
A cross-service workflow can partly succeed because each service commits independently. A saga coordinates local steps and compensating actions to recover when a later step fails. Compensation is a business recovery action, such as refunding a payment, and may not exactly erase every observable effect of the original action.
Turn this concept into a clear answer.
- Describe both the success sequence and the failure after a particular committed step; “use transactions” is insufficient across arbitrary external APIs.
Adapted from 07_SYSTEM_DESIGN_ARCHITECTURE.md · “How do I handle partial failure across services?”. Examples are study fragments; framework behavior can depend on your version.