Why a booking needs a transaction

One booking, several writes

The service above wrote a single row. A real booking write touches more than one: you insert the booking, you insert a hold on the walker's slot so nobody else can grab it, and (next module) you record the charge. Three writes that must all succeed or all fail — together.

Picture them running one at a time and the process crashing between write two and write three: the booking exists, the slot is held, but no charge was recorded. Or worse, the charge went through and the booking insert failed — you took the money and have nothing to show for it. A half-written booking is the exact bug that turns into an angry customer and a manual refund.

The rule for anything money-shaped: writes that belong together must be atomic — all-or-nothing. There is no valid state where two of the three landed.