Saga Pattern

Outcome: Design or review Saga Pattern for this system while keeping data correct, secure, and easy to operate. User context: Order `984` reserves stock, authorizes NT$248, and then asks for shipping. Shipping rejects the address. The saga voids the authorization and releases the stock with the same saga ID. It then records the order as compensated. Technical concept or control: Saga Pattern. Why it fits: Use a saga when one business job spans services or data stores. Use it only when one all-or-nothing database step cannot cover the whole job. Define each saved step, next action, retry, fix-up action, and final state. Do not use it when: Do not add a saga when one database save can finish the whole job. A fix-up action is new work. It can fail or leave a different result. Ask a person when an action is unsafe to undo. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.