Engineering / Practical guide
Preventing double booking: the conflict happens at commit
Why an available slot in the browser is only a proposal, and how to test the backend boundary that protects a reservation.
Why do double bookings happen?
Two requests can read the same available resource before either one saves a booking. If the application only checks availability during the initial page load, both may be accepted. The final write must enforce the availability rule in the authoritative store.
An illustrative race
At time A, two customers open the same 14:00 appointment. At time B, the first confirms. At time C, the second confirms using a stale view. A correct system accepts the first valid commit and returns a conflict for the second. This is a conceptual test sequence, not a measured production incident.
| Step | Request A | Request B |
|---|---|---|
| Read | 14:00 appears available | 14:00 appears available |
| Commit A | Booking accepted | Still viewing stale availability |
| Commit B | No change | Conflict returned, alternatives offered |
Put the invariant close to the data
The invariant might be “this staff member cannot have overlapping confirmed appointments.” The exact implementation depends on the data store and resource model. It may use transactions, locking or database constraints. A JavaScript check is useful feedback but cannot protect the invariant by itself.
PostgreSQL documents range types and exclusion constraints for non-overlapping reservations. That is one implementation option, not a claim that all URVEON projects use PostgreSQL or that one constraint solves every multi-resource model.
Model holds and buffers explicitly
A hold may block capacity until its expiry time; a confirmed appointment may include a cleanup buffer. Decide which states occupy capacity and use the same interpretation in online availability and staff tools.
Rescheduling also needs a clear operation: reserve the replacement and release the original consistently, or preserve the original when the move fails. Avoid a sequence that leaves the customer with neither slot.
Offer a useful conflict response
Tell the customer the time is no longer available, preserve their entered information and offer fresh alternatives. Do not show a successful confirmation and rely on staff to call later. The operational record and the customer message should describe the same state.
A verification checklist
Send two concurrent confirmation requests for the same resource and overlapping time. Assert that only permitted capacity is committed. Repeat with a staff-created booking, an expired hold and a reschedule. Add multi-resource cases if a service needs equipment or a room.
The acceptance criterion is the saved state after competing requests, not whether the calendar looked correct during an ordinary single-user demonstration. Return to the booking guide for the wider state and integration model.
Sources and further reading.
The decision models and examples are URVEON editorial guidance. External implementation facts are supported by the primary references below; provider capabilities should be rechecked during project discovery.