How does ezerve prevent double-booking?

Most booking software checks for conflicts in application code: look up the calendar, see the slot is free, write the booking. Between the look and the write, another request can slip through — that's where double-bookings come from, and why they're usually described as "rare" instead of "impossible".

ezerve moves the rule into the database. An exclusion constraint on the reservations storage itself makes two overlapping holds on the same exclusive asset unrepresentable — the database physically refuses the second write, no matter how the requests race.

When two customers want the same slot

Both tap Confirm in the same instant. Exactly one booking is written; the other request gets an immediate, honest answer — "that time was just taken" — and a fresh set of times. Nobody gets an email that later turns out to be wrong.

Multi-asset bookings are all-or-nothing

A guided tour holds one guide and two kayaks as a single unit. If any piece can't be held — the guide just got booked, the fleet is down to one boat — the whole reservation rolls back and nothing is held. You never end up with a guide reserved for a tour that has no boats.

Capacity assets count seats

Assets with capacity (a fleet of 8, a class of 12) use transactional seat counting instead of exclusion: seats are counted under a lock, so ten simultaneous requests for the last three seats end with exactly three bookings — never four.

Buffers are part of the hold

Turnaround buffers widen the held window. If your kayaks need 30 minutes of rinse-and-stage after each rental, the constraint protects that time too — the next booking can't start until the buffer clears.

What this means for you

Trust the day view. If a reservation is on the calendar, the assets are genuinely held; if a time is offered to a customer, it was genuinely free when offered. There is no "sorry, we double-booked you" email in this product's vocabulary.