Let the database say no: preventing double-booking

Check-then-insert is a race condition with a calendar invite attached. Under load, two requests both read “slot is free” and both happily book it. I learned to stop fixing this in application code and let the database refuse.

The check-then-act trap

SELECT ... WHERE slot is free, then INSERT, has a gap between the read and the write. Two concurrent requests can both pass the check before either inserts. No amount of careful application logic closes that window reliably — you’re just making the race narrower, not removing it.

Make the constraint physical

Postgres EXCLUDE constraints with a range type reject any row that overlaps an existing one — at commit time, inside the engine. The second booking doesn’t get a polite “sorry” from your code; it is physically impossible to store. That’s correctness you can’t forget to write, can’t accidentally bypass, and can’t lose in a refactor.

Timezones are the other monster

“9:00” is meaningless without a zone, and daylight saving means some local times don’t exist while others happen twice. Compute availability with the Temporal API against real time zones, store instants in UTC, and render in the viewer’s zone. Hand-rolled date math is where booking apps go to die.

Side effects need an outbox

The confirmation email must not vanish if the request crashes right after commit. Write the intent to an outbox table inside the same transaction, then deliver it asynchronously. “Committed, will send” beats “sent, maybe committed.”

The theme across all of it: push correctness down to the layer where it can be enforced, not merely hoped for.