An open slot is a preview of availability, not a reservation. Two prospects can view the same time before either commits. Enforce the scheduling invariant at the authoritative write boundary and return a useful conflict result when another request wins. A second availability check improves feedback but cannot close the race by itself.
Begin with the scheduling model: fixed slot starts or arbitrary intervals, one coach or several resources, confirmed states and the cancellation rule. The chosen database constraint must match that model. A guarantee about identical start times is narrower than a guarantee about all overlapping appointments.
Put the invariant beside the write
The reviewed UltraFit360 booking route checks open slots, inserts the booking and maps a uniqueness violation to a slot_taken conflict. The associated migration defines a partial unique index on coach and start time for confirmed bookings. These source observations establish an intended same-start guard, not evidence that the migration is present in every deployed environment.
PostgreSQL documents partial unique indexes as enforcing uniqueness among rows satisfying a predicate. Verify the actual database schema and relevant status transitions in the release under review. If the scheduling model permits arbitrary overlaps, assess a constraint or transaction design appropriate to intervals rather than assuming a start-time key covers them.
PostgreSQL: partial unique indexes
Return a conflict that preserves the prospect’s effort
Illustrative response:
409 Conflict
{ "code": "slot_taken", "refreshAvailability": true }
UI: retain entered details, explain the slot changed,
then let the prospect choose a currently available time.Keep success confirmation after the authoritative commit. Do not send a booking confirmation because a button was tapped or a preview returned open. If confirmation delivery fails after the booking succeeds, preserve the booking and reconcile messaging separately so a retry does not create another appointment.
Read the isolated fixture at its actual scope
| Prospect | Preview | Commit result |
|---|---|---|
| A | Open | 409 conflict |
| B | Open | 201 accepted |
| Final confirmed row count | Same coach and start | 1 |
The fixture uses in-memory SQLite with a partial unique index. Both threads observe the slot before either writes; writes are serialized to isolate uniqueness from SQLite lock behavior. B happened to win this run. This is an algorithm illustration, not a concurrent PostgreSQL benchmark, API execution or proof of a production booking guarantee.
A release test should run the actual route against an isolated database with the real migration and simultaneous requests. Record response codes, confirmed rows and side effects. Keep the test detached from real calendars, payment accounts and customer notifications.
Decide cancellation and retry interactions
The confirmed-state predicate implies that cancellation status matters to the same-start rule. Specify when the slot becomes bookable again, and test a cancellation racing a new request. Also distinguish a duplicate retry from a different prospect; a timed-out success needs an operation identity or another explicit reconciliation path.
CoachAccountable’s first-party API exposes appointment operations and illustrates that booking is a lifecycle, but it does not define this application’s constraint or prove compatibility. Confirm provider access separately for any proposed external connection.
CoachAccountable: appointment API reference
No exact fictional local booking UI was verified, so the researched screenshot becomes a two-request commit diagram. Acceptance should include same-start contenders, changed slot duration, cancellation, a request timeout and failed confirmation delivery. The review artifact is the invariant and its observed test, with narrower fixture evidence labelled honestly.
Distinguish a conflict from an uncertain success. A definitive slot_taken response means the prospect should choose another slot, while a lost response after commit requires checking the original operation’s outcome. Automatically submitting another booking in both cases can create duplicate intent. Preserve a redacted operation reference and a clear pending state for the uncertain case. The recovery test should verify that the prospect can learn which booking exists before being asked to repeat the entire form.
Open the live UltraFit360 Coach portal
Bring one client-to-coach workflow, current data contract and acceptance constraint to discuss a bounded fitness product build or integration pilot.
Explore health fitness app development
Can an open booking slot be treated as reserved?
No. Availability is a preview. The authoritative commit must enforce the scheduling constraint and return a recoverable conflict when another request wins.
Does a second availability check prevent every race?
No. Another request can commit after that check. Enforce the invariant at the authoritative write boundary.