Design for Operations That Partially Succeed

Systems & Architecture · errors, checkout, status

Updated 2026-08-04

Treat any multi-step action as something that can stop halfway. Reserving stock, charging a card, and creating a shipment are separate steps in separate systems, and step three can fail after steps one and two committed.
Never report a partial failure as a plain error. Something went wrong leaves the user unsure whether they were charged, which is the single most alarming state a product can produce.
Say what completed, what did not, and what the system did about it. "Your card was not charged. The items are back in your cart." answers the only two questions the user actually has.
Name the compensating action in the interface, because a saga performs one whether or not you show it:

Give the reversal its own timeline when it is not instant. A refund that takes five business days needs to be stated as five business days at the moment of failure, not discovered later.
Keep the user's input through the whole failure. Anything that took effort to enter must survive a step that failed after it.
Distinguish "not done" from "undone". A checkout that never started and a checkout that was rolled back look identical in the database and feel completely different to a person.
Send the confirmation only for the outcome that actually happened. A success email fired at step two of four is the fastest route to a support queue.

A half-finished operation is normal in a distributed system, and the interface's job is to make sure it is never a half-finished explanation.