BookInnTimeEvery booking system eventually meets the same scenario: two people open the same free slot, and both press book within the same second. Whichever way the screens are drawn, something has to decide that only one of them gets it.
The tempting fix is to check availability just before writing the booking. It is also the wrong one. Between the check and the write there is a gap, and under exactly the conditions that matter — two requests at once — both checks pass and both writes succeed.
Letting the database decide
Instead the rule lives in the database itself, as a constraint that refuses to store two overlapping bookings for the same business. The second write does not get a stale answer; it is rejected outright, and the customer is told the slot has just gone.
This is less clever than it sounds and much more reliable. The check cannot be forgotten by a future change, skipped by a different code path, or defeated by timing, because it is not code — it is a property of the data.
What a customer sees
A short message saying the time was taken while they were deciding, and the grid refreshed around them. Mildly annoying, and far better than two people arriving for the same appointment.