Spotrak
Product team
Two clients open your booking page. The same 2pm slot shows free to both. They tap a second apart. How many appointments now exist at 2pm?
If the answer can be "two," you have a bug nobody sees in a demo and everybody sees on a busy day. Double-booking is the simplest test of whether a scheduling tool was built seriously.
The interface protects nothing
The naive instinct: "we check the slot is free, then we save it." Between the check and the save, the other booking slips through. That window lasts a few milliseconds, and that's plenty. Check-then-write is two operations; between them, anything can happen.
The guarantee lives in the transaction
The only place a slot's uniqueness can be guaranteed is the database, inside a transaction. We don't check before writing. We let Postgres reject the second write, through an exclusion constraint on the time range and the resource. The first booking goes in, the second is refused by the database, not by an if. There's no window, because there's only one operation.
The detail that changes everything: the resource and the time zone
A slot isn't just a time. It's a time, a team member, and sometimes a room or a piece of equipment. Two appointments at 2pm with two different people are valid. At 2pm with the same person, not. So the constraint is on the combination, not on the time alone. And everything is stored in UTC, so a daylight-saving change creates neither a gap nor a duplicate.
These are details invisible to the user. That's exactly why they matter: a good scheduling tool is one where the question of double-booking never even comes up.