Loading...
Loading...
Browse 4 real-world technical and behavioral interview questions about Saga. Review scenarios, edge cases, and architectural best practices.
A saga has no rollback. Each step already committed in its own database and was visible to everyone, so you can only run new forward transactions that semantically offset it. Compensations are not atomic, some actions cannot be compensated at all, and compensations themselves fail - so a saga needs idempotent handlers and an ordering rule for irreversible steps.
Persist the order in a pending state before you touch the payment gateway, quote tax and shipping per seller shipment, authorise once behind an idempotency key, and commit the remaining steps through a transactional outbox and a saga whose compensations void the authorisation and release reserved stock.
The order is decomposed against the product catalogue into technical tasks on separate systems, each with its own latency and failure mode. Because nothing spans them transactionally, correctness comes from idempotent tasks, compensating actions, a fallout queue and jeopardy monitoring.
Draw boundaries on data ownership so exactly one service writes each table, then accept that a workflow crossing them needs a saga of compensating steps and an outbox to make the write and the publish atomic. While the boundaries are still moving, a modular monolith is the honest answer.