Each layer has one job, and any operation that spans several steps can undo itself cleanly when one step fails.
We separate a system into layers that each do one thing. The request handler is thin: it reads input, calls a service, and translates the result for the client. The service holds the business rules — permissions, validation, the legal state transitions of a workflow. Beneath it, repositories own data access and adapters own the outside world: a payment processor, a shipping API, a geocoder. Each adapter presents a clean internal interface, so the rest of the system depends on charging a card, not on the quirks of a specific vendor — and swapping that vendor later touches one file, not fifty.The hard part of real systems is the operation that spans several of those layers at once — a checkout that charges a card, reserves inventory, and schedules fulfillment across separate systems. If step three fails after steps one and two have already written, you are left with a half-finished transaction: a charged customer with no order. We model these flows as sagas. Each step records how to reverse itself; if a later step fails, the recorded compensations run in reverse order, unwinding the partial work until the system is back where it started. The customer is never charged for an order that did not complete.This is the difference between code that works on the happy path and code that is safe in production. Most bugs that reach users are not logic errors — they are half-completed operations that nobody planned the failure case for. Designing the rollback alongside the action, rather than bolting it on after an incident, is what lets a small team run commerce-grade systems without a wall of manual cleanup tools.
In practice: a multi-step checkout charges, reserves stock, and books delivery. If booking fails, the reservation releases and the charge reverses automatically, in order — no half-charged customers, no orphaned orders, no 2 a.m. database surgery.