Saga pattern

A saga coordinates a long-running business process through a sequence of local transactions, each with a compensating action if a later step fails. Orchestration uses a central coordinator; choreography uses events and each service knows its role.

Trade-off: no global lock, but compensations are business logic (cancel shipment, refund partial) and may be imperfect if the user already saw success.

On interviews: design a trip booking saga with payment, seat hold, and notification; specify compensating steps and failure visibility.

Common pitfalls: compensations that cannot undo user-visible effects; missing idempotency on saga steps; no persistent saga state for recovery.

Checklist:

• Model forward steps and compensations explicitly.
• Persist saga state and step outcomes.
• Make each step idempotent.
• Choose orchestration vs choreography by clarity needs.