Half done

Think of it when one action touches more than one place: two services, a file and a database, a payment and an email.

In everyday life

Moving house with three bookings: the van, the cleaner and the keys to the new flat. If the keys fall through, the van still turns up and still sends a bill, unless someone cancels it.

One case

A travel site books a trip in three calls: the flight, the hotel, then the car. On 12 June the flight and the hotel succeed, and the car company’s server is down. The site shows “Booking failed”, but the flight and the hotel stay booked, and the customer is billed for both.

The car failed, and nothing undid the flight and the hotel
The case, cell by cell1 cell = 1 step
Planned
bookedbookedbookeddone
What happened on 12 June
bookedbookedfailednone
Steps left booked
2
Steps undone
0
The site reported one failure and left two bookings in place.

Every case

A program on one machine tends to stop as a whole. A system of many parts fails in pieces: one call works, the next one gets no answer, a third succeeds but its reply is lost. Code written as if every step succeeds leaves records that disagree with each other. A database transaction covers one database. Across services, you must plan for each step how to undo it or finish it later.

The word

Engineers call this

partial failureSome steps of an action finish and others do not, so the system is left half done. In a system of many parts, some part is usually failing while the rest works.

For every action with more than one step, ask: what if it stops after step 1? Design that answer before you write the path where everything works.

Where this idea leads

Skills that encode it

  • principle-make-operations-idempotent pstackAsks “what happens if the previous run crashed at every possible point?” and makes each run converge.
  • statechart pstackChecks every path through a flow’s states and reports the shortest path to a state that breaks a rule.