Web · Implementation study
Online booking that cannot double-book
How availability, time zones, and concurrent requests combine into a booking flow that holds up when two people pick the same slot at the same moment.
What the demo shows
Meridian Studio is fictional. The calendar, slot list, and hold timer are generated in the browser, and confirming a booking updates local state only. No calendar service, payment processor, or reminder email is connected.
Proposed system flow
- 01Availability rules
- 02Resolved local slots
- 03Held reservation
- 04Confirmed booking
01
Separate availability rules from the slots people see
Availability is not a list of open times, it is a set of rules: working hours per resource, service duration, buffer before and after, lead time, maximum booking horizon, recurring closures, and one-off exceptions. Slots shown to a visitor are derived from those rules at request time rather than stored as rows, so a schedule change takes effect immediately instead of leaving stale openings behind. Recurrence is the part teams routinely underestimate; the iCalendar specification exists because repeating events with exceptions, cancellations, and shifted instances are genuinely hard, and matching its data model early avoids a rewrite when a customer asks for every other Tuesday.
02
Treat the time zone as part of the data
A booking has at least three time zones in play: the customer's, the business's, and whatever the server happens to run in. Storing an absolute instant and rendering it in an explicit named zone from the IANA database keeps those consistent, while storing a naive local time guarantees an off-by-one-hour bug at the next daylight saving transition. Recurring rules must be expressed in the business's local zone so a nine o'clock appointment stays at nine o'clock across the change, and the confirmation screen and reminder email should both name the zone rather than assuming the reader shares it.
03
Make the race condition impossible, not unlikely
Two visitors loading the same slot list and both clicking confirm is the normal case, not an edge case, and checking availability then inserting a booking in two separate steps loses that race. The write path needs the database to arbitrate: a uniqueness constraint on resource and time interval, a transaction at an isolation level that actually prevents the anomaly, or an explicit lock taken on the resource row for the duration of the check-and-insert. A short server-side hold placed when the customer opens the form, with an expiry that releases it automatically, keeps the interface honest about what is still available while payment or intake details are collected.
04
Design the failure states, not just the happy path
The slot the customer wanted will sometimes be gone by the time they submit. That path deserves the same care as the success path: explain what happened, keep everything else they entered, and offer the nearest alternatives without a full page reset. The same applies to a hold that expires while a form sits open, a payment that fails after a slot is held, and a cancellation that arrives inside the notice window. Each of those needs a defined outcome and a record, because the argument that follows a disputed appointment is settled by the audit trail rather than by memory.
Validation plan
- Fire concurrent confirmations at the same slot from multiple clients and verify exactly one succeeds and the rest receive a clear conflict response rather than a duplicate booking.
- Test across a daylight saving transition in both directions, with customer and business in different zones, and confirm reminders and calendar entries land at the intended local time.
- Verify holds expire on the server rather than relying on a browser timer, and that an abandoned form releases its slot.
- Walk the flow with a keyboard and a screen reader, confirming the calendar grid and the slot list are both operable and that availability changes are announced.
More in web
Have a similar problem to solve?
Discuss your project