Distributed Transaction Patterns 
Distributed transactions span multiple services that each own their own data, with no shared database transaction to roll back. These patterns coordinate the steps, undo completed work when a later step fails, and keep external side effects correct under retries.
Patterns in This Section
Choosing a Pattern
You need to undo completed steps when a later step fails: use the Saga Pattern and define a compensation for every step that has an external effect.
You need to respond to the caller before the transaction finishes: use Early Return to acknowledge after initialization and continue processing in the background.
Related Sections
- Error Handling & Retry Patterns — control how each step retries before a compensation triggers
- Workflow Messaging Patterns — the Update-with-Start mechanism behind Early Return
- Performance & Latency Patterns — combine Early Return with Local Activities for the lowest first-response latency