Avid Lab Tek · Senior Full Stack Developer & Solutions Architect / Founder

Fixed Booking Race Condition with Postgres Exclusion Constraints

I built CommiShare, a booking platform for shared commercial kitchens, and deployed it to a live client. Food vendors use it to book prep tables and equipment against monthly contract-hour quotas — a scheduling process that previously lived entirely outside any system, leaving the kitchen operator to manually resolve conflicts whenever two vendors showed up expecting the same station. While reviewing my own booking code, I realized I'd made a flawed assumption: that wrapping a booking in a database transaction was enough to prevent two vendors from grabbing the same station simultaneously. Nobody flagged this — I traced through what happens when two requests arrive at the same moment and couldn't convince myself the conflict check was actually protected. Digging into what my isolation level actually guaranteed, I confirmed that transactions provide atomicity, not isolation from overlapping writes, meaning two concurrent requests could both pass the conflict check before either committed. I fixed this by moving the guarantee out of application code and into the database itself, using a Postgres btree_gist exclusion constraint over station_id and a tstzrange of the booking window, so Postgres rejects any overlapping row outright regardless of how requests interleave. I treated verification as more important than the constraint itself: reasoning about correctness isn't proof, so I wrote a test that fires two concurrent booking requests at the same slot and asserts exactly one commits while the other returns a conflict — not that both silently succeed. I also made sure the API translates the constraint violation into a clean 409 response rather than a 500 error, so clients see a proper conflict instead of a crash. As the sole owner of the platform's full lifecycle — customer conversations, schema design, NestJS and React implementation, layered auth, background jobs, and CI/CD with versioned migrations on every merge — this fix ensures the operator's schedule and billable contract hours can never disagree. A conflicting booking is now refused at write time by the database itself, rather than surfacing later as a person-to-person dispute. The platform is actively in use with a real client today, and this database-level guarantee replaced what used to be manual conflict resolution.