Understand first
New to this knowledge point
Complete the prerequisite concepts, read the principles and counterexamples, and then explain why in your own words.
Start with core principles →Knowledge catalogChoose core direction and segmented content
Understand → Implement → Debug → Design
Committed effects and conditional compensation in sagas
Examine cross-service transactions, compensation conditions, irreversible actions, and human intervention.
Knowledge content check2026-10-03 · Check the source of the original question2026-10-02
It is recommended to understand first:
Idempotency, unknown outcomes, and task recovery →Which step do you want to learn from this knowledge point?
Select the starting point based on the current basis, or you can go deeper one by one. When you encounter an unfamiliar concept, go back to the core principles first; use the knowledge exercises to check your understanding when you are finished.
Realize again
Prepare to write the principles into code
Understand implementation steps and boundaries, complete small tasks, and check results against acceptance requirements.
Reading implementation and trade-offs →Will troubleshoot
Need to handle failures and changes in conditions
Follow the continuous questioning to locate the failure premise, and then compare the migration cases to explain how the plan should be adjusted.
Continue to delve deeper into the problem →Able to choose
Need to design or review plans
Combine engineering deductions and senior self-evaluation standards to explain the applicable conditions, costs and alternatives of the plan.
Analyze engineering scenarios →Knowledge unit directory
LEARN · PRACTICE · REFLECT
Knowledge learning and personal records
First read along the principles, Q&A and migration cases. When you need to check your understanding, switch to reinforcement exercises or start personal recording.
Answers and personal notes
Can be practiced directly. After logging in, answers, favorites, and notes will be saved to your account.
Log in and saveEach modified commit will be kept as an independent history. Your level of mastery is up to you to evaluate yourself against the standards.
Core concept · Committed effects and conditional compensation in sagas
Understand the core principles first
Preparatory concepts:Cross-service transactions, Unknown results and reconciliation, Business authorization
Compensation is another business action that may charge, fail, or be irreversible, not erase history. First confirm the positive results, and then decide whether to compensate according to the terms, dependencies and authorization. The compensation itself must also be recoverable.
Local failure does not establish remote failure
A flight timeout may follow ticket issuance, and a hotel may already be booked. Resetting local state discards facts without cancelling reservations. Reconcile stable booking IDs into success, failure, or unknown. An unknown result must not directly trigger cancellation of a potentially valid itinerary.
Compensation restores an acceptable business state
Database rollback reverses uncommitted writes; Saga compensation addresses committed effects across systems. Refunds may retain fees, and deleting a report cannot undo readership. Record receipts, compensation actions, conditions, deadlines, and non-compensable outcomes. Dependencies determine ordering: reverse dependent steps where appropriate, parallelize independent resources, and prioritize required protective actions.
Compensation has its own uncertainty and races
A cancellation timeout may hide successful cancellation. Reconcile or retry idempotently using the same compensation_id. Forward and compensating actions need distinct identities and histories. Concurrent compensation or manual order changes require business-version checks. AWS Saga guidance emphasizes participant idempotency and the absence of transaction isolation; an orchestrator’s old records cannot replace current business state.
Explain the unresolved boundary
Expose booked, awaiting confirmation, compensating, compensated, or manual-review states rather than claiming everything rolled back. Costs and disclosures stay within approval scope; inadequate scope requires concrete choices. Test confirmed failure, unknown issuance that later succeeds, non-cancellable hotels, lost cancellation responses, and expiry. These are design exercises; target-system terms and effects require actual validation.
Check understanding with a question
Agent has booked a hotel but the flight ticket failed. Should the hotel be automatically canceled?
Check authorization, cancellation terms, and whether failure is confirmed. Compensation is a business action, not database rollback. Record receipts, conditions, and deadlines, using idempotent operations for compensation. Reconcile unknown flight outcomes before cancelling hotels. Costly or irreversible actions remain within approval scope or wait for confirmation, with honest current-state reporting.
Realization and trade-offs
First determine whether it is failed or unknown.
If the ticket interface times out, the ticket may have already been issued, and directly canceling the hotel will create inconsistencies. Use the order number to check the ticket status and separate unexecuted, executed and unknown. When there is no single database transaction across systems, submitted facts should be managed according to business processes; any local status rollback cannot erase hotel orders.
Design compensation actions
The steps define positive actions, success receipts, compensatory actions, compensation prerequisites and non-compensable reasons. Refunds, cancellations, or corrections are not the exact reverse of the original action and may be subject to fees or external notifications. Compensation is arranged according to dependencies, independent steps can be parallelized, and strongly dependent steps must be in business order; all steps cannot be deleted unconditionally in reverse order.
Compensation will also fail
Compensation requests require their own operation_id and receipt verification, and retries are still subject to budget and deadline constraints. The status distinguishes between compensating, compensated, compensation_failed and manual_review. Let humans see which actions have been completed, which ones have failed, and next-step options, instead of uniformly displaying "task failure."
Validate with a fault matrix
The hotel test is successful but the ticket fails, the ticket is confirmed successfully after timeout, the hotel cannot be canceled, the response to the compensation request is lost, and the user cancels midway. Acceptance depends not only on the final business status, but also on whether unauthorized expenses and repeated compensation have occurred. The Saga model of the framework provides orchestration ideas, and the legality and economic losses of compensation are still determined by business rules.
Engineering deduction
- scene
- Interview hypothesis: After the itinerary agent books the hotel, the ticket call times out.
- design decisions
- Check the ticket order first, and then decide on compensation based on the cancellation terms and user authorization.
- Verify target
- The user sees the actual booking state, and a person can take over if compensation fails.
- applicable boundary
- This is a process design issue, and the actual costs and cancellation rules are determined by the supplier.
Continuous questions and answers
Continue reading along with the premises and constraints of the problem. Understand the reference answers first, then try to put away the answers and explain the cause and effect and trade-offs in your own words.
Level 1If I cancel a hotel, I will be deducted. Will the original approval cover it?
From whether to compensate to the authorization and economic conditions of the compensation action itself.
Reference answer
Coverage is only possible if the original approval clearly contains the corresponding cancellation conditions and fee caps, and "agreement to loss of fees" cannot be inferred from "agree to book". Recheck the current cancellation terms, amount and deadline. If it exceeds the scope, it will be suspended and the specific price will be displayed for confirmation. It is also necessary to avoid waiting for fee changes and explain the deadline to users.
Level 1What should I do if the compensation request also times out?
In addition to the forward unknown, compensation also has a remote success local unacknowledged window.
Reference answer
Record the compensation result unknown, check the status with the same compensation_id or order number; confirm the receipt if it is canceled, and do not repeatedly create refunds and other actions. If the target supports idempotency, you can retry along the same key, but it is still subject to the deadline and budget; if it cannot be queried, it will be manually verified, and it cannot be claimed to have been rolled back.
Follow this answer further
Level 2If the query shows that it is still valid, can I cancel it immediately?
After the parent asks for reconciliation, the conclusion may still be unknown due to query consistency and asynchronous status.
Reference answer
First understand whether status query is strongly consistent and whether cancellation is asynchronous. The old view "valid" may correspond to cancellation processing, retry along the same compensation identity instead of creating a new action; wait for the agreed visibility window and check the processing receipt. Just because one query has not changed does not prove that the last cancellation failed.
Follow this answer further
Level 3The cancellation deadline is coming soon and I still can’t find it. Should I retry automatically or wait for manual work?
Uncertain results add time pressure, requiring business strategies to be defined in advance instead of just guessing in the event of a failure.
Reference answer
Determined according to the predefined authorization and risk strategy: if the target supports idempotency and the cost is within the range, you can retry with a limited number of keys; if it does not support it and the risk of repeated costs is uncontrollable, it will pause, alert and provide status. You cannot use a model to guess risk preferences temporarily. Record the deadline and attempted actions so that humans have specific facts to judge.
Level 1Do all compensations have to be in reverse order?
Compensation mechanisms further require understanding dependencies rather than stack operations.
Reference answer
Mechanical reverse order is not necessary. According to the business dependency graph arrangement, the downstream dependencies should be removed first to avoid orphaned resources; independent steps can be parallelized, and some protection actions should be executed first. Compensation may not be restored to its original state. When designing, clearly state the premise and sequence reasons for each step, and do not regard "the last thing done first, delete it first" as a general proof.
Draw inferences from one example: If the conditions change, how to deduce it?
First find out the conditions for change, and then determine which premises in the original plan still hold true. The following cases are teaching deductions to facilitate the transfer of principles to new problems.
Report published publicly
Changing conditions:Action affects third-party readers
Extended question:Is deleting the files complete compensation?
Derivation and reference solutions
No, readers may have downloaded or acted based on the report. You can remove the entry, publish corrections, and notify affected persons, but each action has its own authorization and receipt, and you cannot revert to never publishing. The status should indicate which effects can be handled and which are irreversible. It cannot show "transaction rolled back".
The principles that remain unchanged:Compensation improves the current business status without erasing the information dissemination that has already occurred.
Inventory has been deducted but payment is unknown
Changing conditions:The two facts of funds and inventory are not determined at the same time
Extended question:Can the stock be replenished immediately?
Derivation and reference solutions
Check the payment result first; if the payment is successful but the inventory has been replenished, it may result in the payment being out of stock. Using retention status and timeout rules, the inventory will not be resold during an unknown period, and fulfillment or refund will be determined based on the authoritative payment receipt. Different businesses can choose risk strategies, but the consistency window for funds and inventory must be clear.
The principles that remain unchanged:Compensation requires confirmed facts and dependency conditions, and timeout does not automatically trigger reverse actions.
Easy to make mistakes
- Timeout directly treats failure
- All actions are assumed to be undoable
- Compensation failure still shows that it has been rolled back
References
It is designed based on public technical information; the reference materials support the technical mechanism, and the scenarios and scoring standards are designed by this website and do not represent the original interview questions of a certain company. New Q&A and migration cases are added for principle explanation, and source verification and case operation verification are recorded separately.
Check how far you understand
After reading, you can explain the principles, boundaries, and trade-offs against these standards. It is up to you to evaluate your mastery; if further verification is needed, complete the small tasks below.
- Basic standards met
- Ability to distinguish between indelible external facts and compensatory actions permitted by the business.
- Intermediate and advanced signals
- Design receipt verification, compensation prerequisites and step-by-step status.
- Senior Signal
- Ability to handle reimbursement failures, expense authorizations and manual closeouts.
Hands-on verificationComplete on demand · Suggestions15 minutes
List the failure matrix and allowable compensatory actions for the two-step hotel and flight processes.
Expand acceptance requirements and checkpoints
- Unknown results should be verified first
- Charge action recheck authorization
- Compensate for failure without pretending to be successful
Key inspections
- Compensation is not considered a database rollback
- Check for unknown results first
- Compensation has authorized, idempotent and failed states