Booking test cases, for the slot that sells twice

Every serious booking defect is the same defect: finite inventory sold more than once. It happens through concurrency, when two confirmations read the same availability and both write, and it needs a conditional update or a lock rather than a check followed by an insert. It happens through stale availability, when the search result is trusted at confirmation instead of being rechecked. And it happens through holds, which solve the checkout race but introduce a leak of their own: a hold that is never released because the customer closed the browser removes that slot from sale permanently, and there is no order anywhere to explain where it went.

The payment boundary is the most damaging place to fail. A charge that succeeds while the booking write fails leaves a customer who has paid for nothing, and unlike an oversell there is no partial service to offer. The transaction has to either reverse the payment automatically or complete the booking, and any discrepancy has to be surfaced rather than logged quietly. The related case is the timed out confirmation: an outcome that is genuinely unknown must never be presented as a failure, because the customer will immediately book again and now there are two reservations and two charges.

Time is where booking systems accumulate subtle bugs. A slot is only meaningful in the venue timezone, so comparisons against now, cancellation windows and booking horizons all have to use it rather than the customer device clock. Daylight saving transitions produce an hour that does not exist and an hour that happens twice, and a duration calculated by clock arithmetic rather than elapsed time is wrong across both. Adjacency needs deliberate treatment too: a booking ending at ten and another starting at ten is legitimate, while any real overlap is not, and a changeover buffer has to apply consistently at both ends.

Modification is where a well built booking flow still loses a customer reservation. Changing a date means securing new inventory and releasing the old, and doing it in that order matters: release first and a failure partway leaves the customer with nothing. Repricing has to be exact across rate rules, the quoted price has to hold for the duration of the hold or be re-accepted explicitly, and every confirmation message after a change has to supersede the earlier one rather than contradicting it in the customer inbox.