Engineering note
Transactional boundaries for competing reservations
Treat pending requests as intent, then make acceptance the inventory-claiming transaction. Lock the reservation target first, recheck availability, commit one winner, and close overlapping requests coherently.
By Raphael Mansueto · Reviewed
One transaction decides the inventory outcome
Requests can coexist until acceptance; the database boundary resolves contention before any realtime projection updates.
- Record intentPending requests do not falsely remove inventory from other players.
- Lock the targetAcceptance locks the court, coach, umpire, or grouped target first.
- Commit one outcomeAvailability is rechecked and exclusion constraints remain the final guard.
- Resolve competitorsOverlapping requests close with explicit reasons in the same coordinated decision.
Do not confuse a request with inventory ownership
If the first pending request blocks a time slot, an unanswered request can make valid inventory appear unavailable. KudosCourts records pending requests as intent instead. Several players may request the same visible time until an authorized acceptance decides which request claims it.
Lock the scarce target before reservation rows
The acceptance command locks the reservation target, rechecks the current state, and then changes the selected request. A deterministic target-first order gives concurrent commands the same contention boundary. PostgreSQL exclusion constraints remain the final database guard against overlapping accepted inventory.
Resolve the complete decision atomically
Accepting one request is not complete if competing requests remain actionable. The command commits the winner and closes affected overlaps with explicit resolution reasons. Grouped reservations use the same coordinator and resolve all-or-nothing so a player does not receive an unexplained partial booking.
Keep secondary delivery outside the booking decision
Notifications and realtime delivery should follow the committed outcome without deciding it. A provider failure must not roll back a valid booking. The trade-off is that secondary delivery becomes best-effort and needs its own retry or recovery path.
This boundary protects overlapping accepted inventory; it does not make venue-maintained availability fresher than its source data.