Build fluency in the vocabulary of explicitly undoing an earlier completed step across independent services.
0 / 5 completed
1 / 5
At standup, a dev mentions that when the fourth step of a five-step order process fails after the first three steps already succeeded across independent services, the system runs an explicit action to semantically undo each of those completed steps, since no single database transaction spans all five services to roll back automatically. What is this undo action called?
A compensating transaction is exactly this: it is an explicit action that semantically undoes the effect of an earlier completed step in a multi-step process, such as issuing a refund to undo a payment that already succeeded, used when true rollback isn't possible because the steps span independent services with no single database transaction covering all of them. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This explicitly-undo-what-already-succeeded approach is exactly why compensating transactions are the standard way to unwind a partially completed process across independent services.
2 / 5
During a design review, the team defines a refund action as the compensating transaction for a payment step in an order process, specifically because if a later step, like reserving inventory, fails, the system can explicitly undo the already-completed payment instead of leaving the customer charged with no order fulfilled. Which capability does this provide?
Defining a refund as the compensating transaction here provides a defined way to undo an already-completed step when a later step fails, since the refund compensating transaction explicitly reverses the payment's effect, instead of leaving the customer charged with no way to undo it when inventory reservation fails afterward. Having no compensating action defined at all means a failure in a later step leaves the earlier, already-completed step's effects in place with nothing built to reverse them. This explicitly-defined-undo-action behavior is exactly why compensating transactions are planned as part of designing a multi-step process across independent services.
3 / 5
In a code review, a dev notices an order process charges a customer's payment method as its first step, but if a later inventory-reservation step fails, nothing in the code reverses that payment, leaving the customer charged with no order ever fulfilled. What does this represent?
This is a missed opportunity to define a compensating transaction, since an explicit refund action would undo the already-completed payment when a later step fails, instead of leaving the customer charged with no order fulfilled. A cache eviction policy is an unrelated concept about discarded cache entries. This no-defined-way-to-reverse-a-completed-step pattern is exactly the kind of gap a reviewer flags once a process spans independent services with no single transaction to roll it all back.
4 / 5
An incident report shows customers were charged for orders that were never actually fulfilled, because an inventory-reservation step failed after the payment step had already succeeded, and no compensating transaction existed to reverse that payment automatically. What practice would prevent this?
Defining a refund as the compensating transaction for the payment step means it's automatically reversed if a later step, like inventory reservation, fails. Continuing to charge the payment as the first step with no defined compensating transaction regardless of how often a later step's failure leaves a customer charged with no order fulfilled is exactly what caused the incident described here. This define-a-compensating-transaction approach is the standard fix once a multi-step process across independent services is confirmed to need a way to unwind a partial failure.
5 / 5
During a PR review, a teammate asks why the team defines an explicit compensating transaction for the payment step instead of simply wrapping the entire five-step order process in one traditional database transaction that rolls everything back automatically on any failure. What is the reasoning?
A compensating transaction works even when the five steps span independent services with their own separate databases, where no single traditional transaction can span all of them, while a traditional all-in-one database transaction only works when every step shares the same database, which usually isn't true once a process spans independently owned services. This is exactly why compensating transactions are the standard way to unwind a multi-step process across independent services, where a single spanning database transaction simply isn't an option.