Distinguish a failure from an unknown outcome
A timeout may mean the server finished but the response was lost. Before repeating a side effect, look up its operation ID or use an idempotency key. Retry transient errors with a bounded delay; do not retry invalid input forever.
Track state explicitly
Use states such as received, validated, awaiting approval, submitted, and confirmed. Record the operation identifier and enough context to resume safely. A log message alone is not a durable record of completion.
Recover one item without replaying everything
For a batch, track each item separately. Keep successful results, isolate failed items, and let users retry only eligible failures. Define compensating actions for reversible steps, while recognizing that an already sent message cannot be unsent by rolling back a database.
A worked example
Keep the same idempotency key when retrying and reconcile against the provider’s recorded operation. Mark the item as uncertain until confirmed. Do not generate a new invoice number on every retry.
The point: A network error does not prove that the business action failed.
Before you take the exam
Explain these concepts in your own words, work through a different example, and describe why the tempting alternatives fail. Use the references to go deeper.