Concurrent requests are handled safely

Application-level availability checks followed by unguarded inserts are the leading cause of double bookings in production systems. Under concurrent load, two requests can both read "slot available," both pass the availability check, and both insert a booking record — all before either transaction commits. CWE-362 (race condition) and OWASP A04 (Insecure Design) both apply. A database-level UNIQUE constraint is the only mechanism that enforces the invariant atomically: the database serializes concurrent writes and rejects the duplicate at the storage layer, regardless of application concurrency.

Add a UNIQUE constraint to your schema so the database enforces the invariant even when application-level checks race. Add this in prisma/schema.prisma (or the equivalent SQL migration).

model Booking {
  id        String   @id @default(cuid())
  slotId    String
  startTime DateTime
  status    String

  @@unique([slotId, startTime]) // database-level enforcement
}

Then handle the unique constraint violation in your handler and return a structured 409 Conflict response.