Trace both requests at the write boundary
A displayed free slot is an observation, not a reservation. HTTP conditional writes can reject stale state when supported, but the booking service must enforce its conflict rule atomically. This sample assumes one room, one slot and a versioned reservation contract.
| Request | Read state | Commit result |
|---|---|---|
| CMD-A | Slot free, revision 5 | Confirms BK-A; revision becomes 6 |
| CMD-B | Same slot/revision 5 | Refused as stale or conflicting |
| Retry CMD-A | Response was lost | Returns/reconciles BK-A, no second booking |
Keep rejection distinct from pending
After losing the race, refresh availability and offer alternatives without marking the customer confirmed. A changed slot selection is a new authorised intent. Test simultaneous writes, stale revision and a lost success response; a single-user demonstration misses the race.
Both clients checked availability before either wrote. Can both be confirmed?
Show the worked answer
No under this one-slot contract. The controlled write must choose at most one confirmed reservation. The loser receives a clear conflict/stale outcome and must choose again.