Reversibility is mostly something you build, not something the domain hands you. Settlement is the clean case. The only coupling between order and settlement is order publishing `order-paid`, `sub-order-delivered`, and `sub-order-refunded` to Kafka and moving on [9]. Take settlement down and those events queue unconsumed while checkout, payment, and fulfillment carry on untouched [10]. What makes that late rather than lost is two properties the author names explicitly: Kafka retains the backlog, and settlement's consumer is idempotent, so consuming a day of queued events produces the same end state as consuming them on time [11]. Drop the retention window or the idempotence and the same business event, a vendor payout, stops being recoverable and belongs in the other column [17].
The inventory reservation goes the other way, and the reason is visible in a WHERE clause. The conditional update either commits or it does not [8], and `order.create()`'s synchronous call to the reserve endpoint has no fallback path, deliberately [5]. The fallback on offer would be to let the order through and reconcile inventory later, which means selling the last unit of a scarce SKU to five buyers and discovering it when four of them cannot be shipped what they paid for [6]. So checkout answers 503 and asks the buyer to retry [7]. That is the invariant declining to guess, and it is the cheaper of the two errors [6].
That cached-token path is only half of the gateway. A brand-new login does have to reach auth, and it has to fail rather than accept a token it cannot verify; the author calls the alternative "a security regression wearing a resilience costume" [14]. So one component sits in both columns, which means the deciding unit is the request path and not the service [16]. Any table drawn per service has at least one row that is really two.
A single global rule fails for a mechanical reason: the columns differ in whether a later correction can still reach the damage, and services on the same diagram do not carry the same kind of risk [3][2]. Settlement is the newest row in that table, and it exists only because milestone M3 added a sixth service [15]. This is one engineer's system, so the transfer conditions matter. For the degrade column to hold, your retention has to cover your worst outage and your consumer has to survive replay [11]. For the fail-fast column to mean anything, your reservation has to be a conditional update rather than a read followed by a write [8]. Sorting the table is cheap. Earning the invariant that lets a service sit in the degrade column is the work [11].
