SagaPattern
Managing consistency across a multi-step, multi-service operation without a single ACID transaction — via compensating actions.
Why we need this / what value this brings
Lets you maintain consistency across a multi-step operation that spans services/systems where a single ACID transaction isn't possible.
When to use this
Only once a workflow genuinely spans separate services/databases — using it inside a single-database monolith is unnecessary complexity.
How to use or implement this
Define each step and its compensating (undo) action explicitly; execute steps in order, running compensations in reverse if a later step fails.
Research questions
- If booking + payment + notification ever become separate services, what's the compensating action if payment fails after booking is created?
Empty folder — drop notes, links, and findings here as you research.