Pessimistic locking is used

For multi-step flows with meaningful capacity constraints, optimistic locking (version fields) surfaces conflicts only at the final commit — after the user has filled the booking form and possibly entered payment details. CWE-362 (race condition) describes the hazard: concurrent requests succeed their availability checks, race to commit, and one fails at the very last step. Pessimistic locking with FOR UPDATE queues concurrent requests sequentially, so each one sees the committed state of the previous one and the user receives immediate feedback before investing time in the flow.

Acquire a row-level lock on the slot before inserting, inside a transaction. Apply this in your booking service (e.g., src/lib/booking-service.ts).

-- Raw SQL inside a transaction
BEGIN;
SELECT id, booked_count, max_capacity
  FROM slots
  WHERE id = $1
  FOR UPDATE;  -- locks the row for this transaction
-- check capacity, insert booking
COMMIT;

With Prisma, use $queryRaw with FOR UPDATE inside a $transaction callback.