🛡️ Scheduling & Availability

Double-Booking Protection

Two customers can't take the same slot. The database makes sure of it.

Shipped December 27, 2025

✦ Key takeaways

  • Double-booking prevention lives in the database transaction layer, not in application code that can race under concurrent load.
  • A slot is either available or it isn’t — Freebo never shows “1 spot left” to two customers simultaneously without one of them getting a clean rejection.
  • All booking surfaces — public checkout widget, operator dashboard, and the REST API — go through the same locking path.

Double-bookings have a cost that shows up in the worst moment: a customer shows up at the dock and there’s no seat for them. Then you’re on the phone apologizing, refunding, and possibly losing that customer for good.

Most booking platforms prevent double-bookings at the application layer — they check current reservations, see the slot is open, and create the booking. That’s fine for light traffic. Under concurrent load, two requests can both pass the availability check before either one commits. Both bookings go through.

Freebo prevents this with database-level row locking. When a booking is being committed, the relevant asset records are locked inside a database transaction. Any concurrent booking attempt for the same asset and time window waits for the lock to release, then re-evaluates availability. One succeeds. The other gets a clean “unavailable” response.

The application layer checks availability to show the customer what’s open. The database layer enforces it so two customers can never both be right.

— Freebo Engineering, System Design Note

What this covers

  • Public checkout: Two customers racing to the last open slot on a sold-out tour
  • Operator dashboard: Staff manually booking a slot that a customer just took online
  • API integrations: Reservation creation via the API goes through the same locking path as the UI
What does the customer see when a slot fills up during their checkout?
They get a clear error message explaining the slot is no longer available and are directed back to the date picker to select a different time. No silent failure, no confusing partial state.
Does this work for flex-duration products where customers pick their own end time?
Yes. For flex-duration bookings, the asset lock covers the entire requested duration window. A 3-hour charter blocks the asset from departure through return, so no other booking can overlap that window.