I would start with the actual effect, not the workflow engine's label for the step. A retry repeats an attempt to complete the same logical operation. Compensation is a new operation meant to mitigate a confirmed earlier effect. It does not run time backward. Both can fail.

A genuinely side-effect-free read is usually safe to repeat. But the answer it returns may change. If the subsequent decision requires a consistent snapshot, carry a version or transaction boundary, or check the source again before writing. A read of a rate-limited paid API also has cost and may require a retry budget, even if it is safe in the business sense. “Read” describes intent, not necessarily a pure implementation.

An email is externally observable and generally cannot be unsent. If the send call times out, don't assume nobody received it and send again with a new ID. Use a provider-supported deduplication or submission status contract if available, with a stable message operation ID. If none exists, reconcile from the provider's records or mark delivery uncertain. A follow-up correction email is a new effect, not compensation that erases the first. If the email contained sensitive information, an apology cannot undo disclosure. This is why high-impact content needs checks before send.

A payment may be safe to retry under a documented idempotency contract that covers the same amount, recipient, and operation identity during its retention window. It is not safe merely because the HTTP method or workflow activity is retried. If a payment was confirmed and the business wants to reverse it, use the provider's actual refund or void operation, with a separate authorization and ledger entry. A refund can settle later, incur fees, or fail. It does not make the original charge never exist. Temporal's Activity documentation emphasizes idempotence because activity execution can be retried. Stripe's idempotency contract illustrates why key retention and saved first responses need attention.

I would write the state machine around evidence of effects: not_submitted, submitted_unknown, confirmed, compensation_requested, compensated, compensation_failed, and a path for manual resolution. Names can vary, but the unknown and failed-compensation states cannot collapse into “rolled back.” Each attempted payment and refund needs its own stable identity and provider receipt. The user's final view should say whether they were charged, whether a reversal is pending or failed, and what will happen next.

The interviewer then makes compensation fail. Retry it only if its own contract makes that safe, possibly after backoff or a transient fault. Otherwise hold the case for reconciliation or an operator. Do not trigger a new charge to “restore” symmetry or mark the saga complete just because a compensating activity ran. Microsoft's saga pattern describes compensating transactions as a coordination approach, but the business has to decide whether the remaining state is tolerable and who owns it.

One more push is an email sent after the payment but before the refund fails. The customer now has an incorrect receipt. The workflow should send a carefully authorized status correction only after it knows what it can truthfully say. This is why I order irreversible communication after confirmation when the product allows it. The design goal is honest, recoverable outcomes, not a neat green chain of steps.