Booking System
Build a real booking system with availability, slot selection, and double-booking prevention.
The route
6 steps to Done
- 01
Define the booking model
Slots, durations, and conflict rules must be explicit before building UI.
Preview prompt + verify gate ▾ Hide ▴
Define the booking spec. Specify: what is being booked (service/resource) and its schedulable hours; slot duration and how slots are computed for a given date; the booking record (user, resource, start/end datetime, status); the conflict rule (a slot with an active booking is unavailable); and cancellation policy (cancel frees the slot). State that conflicts are enforced at the database/backend level.
- ✓ Slot duration and hours are defined
- ✓ Booking record fields are listed
- ✓ Conflict rule is explicit and server-enforced
- 02
Build availability display
Show real availability computed from actual bookings.
Preview prompt + verify gate ▾ Hide ▴
Implement the availability view. Requirements: a date picker (past dates disabled); for the chosen date, compute slots from the schedulable hours and mark each available/unavailable based on existing bookings from the database; visually distinguish the two states; loading state while fetching; empty/closed state for non-working days. The availability must come from a backend endpoint, not client-side guessing.
- ✓ Past dates cannot be selected
- ✓ Booked slots show unavailable
- ✓ Changing the date refetches availability
- 03
Implement booking creation
Booking must persist and re-verify the slot server-side at submit time.
Preview prompt + verify gate ▾ Hide ▴
Implement booking a slot. Requirements: clicking an available slot opens a confirmation (slot time, resource, user details if needed); confirming calls the backend which re-checks the slot is still free before inserting the booking (reject with a clear conflict error if taken); success shows a confirmation with details and the slot immediately turns unavailable; failures show visible errors. Logged-out users are asked to log in first if auth exists.
- ✓ Booking survives refresh
- ✓ The booked slot becomes unavailable
- ✓ A stale/taken slot returns a visible conflict error
- 04
Prevent double booking under race
Two users clicking the same slot must not both succeed.
Preview prompt + verify gate ▾ Hide ▴
Harden double-booking prevention. Requirements: enforce uniqueness on (resource, start datetime) for active bookings at the database level or with an atomic check-and-insert; simulate the race by attempting two rapid bookings of the same slot (two tabs or scripted double-call) - exactly one succeeds, the other gets the conflict error UI; document the mechanism used.
- ✓ Simultaneous double-book was actually simulated
- ✓ Exactly one booking record exists
- ✓ The loser sees a clear conflict message
- 05
Build my-bookings with cancel
Users must see and manage their bookings; cancel must free slots.
Preview prompt + verify gate ▾ Hide ▴
Implement booking management. Requirements: a my-bookings list (upcoming and past sections) from the backend for the logged-in user; each upcoming booking shows details and a cancel button with confirmation dialog; cancel updates status server-side and the slot becomes available again immediately; past bookings are not cancelable; loading and empty states.
- ✓ Only my bookings appear
- ✓ Cancel frees the slot in availability view
- ✓ Past bookings cannot be canceled
- 06
Booking QA pass
Verify the full lifecycle and edge cases with evidence.
Preview prompt + verify gate ▾ Hide ▴
Run the booking QA and report PASS/FAIL with evidence: book a slot and refresh (persists, slot blocked); second account cannot book the same slot; cancel frees it; past dates blocked; double-book race yields one winner; mobile layout at 375px works for the slot grid. Fix all failures and re-run.
- ✓ Two-account conflict test executed
- ✓ Race test executed with evidence
- ✓ Cancel/free verified in availability
- ✓ All failures fixed