How Do You Stop Two People From Booking the Same Seat?

1. You select A10. Someone else selects A10.

Both press Book. Who gets the seat?

Theatre booking looks like a UI problem. It is mostly a concurrency problem: many clients, one scarce row, money in the middle.

2. The naive implementation

Read free. Write booked. No transaction wrapping both. Under concurrency, that is how you invent extra inventory.

3. Why the race happens

Checking availability and changing availability are two operations. Unless one protected transaction owns both, another request can slip into the gap.

4. Pessimistic locking

Lock the row before you decide. In PostgreSQL and MySQL/InnoDB, a common tool is SELECT … FOR UPDATE: it acquires row-level locks on the selected rows inside the current transaction — not a whole-database lock.

BEGIN;
SELECT status
FROM seats
WHERE show_id = $1 AND seat_number = 'A10'
FOR UPDATE;

-- only one transaction holds A10 here
UPDATE seats
SET status = 'BOOKED'
WHERE show_id = $1 AND seat_number = 'A10';
COMMIT;

5. Row lock vs database lock

Locking A10 should not freeze the theatre. Row-level locking lets another transaction work on A11, A12, B10 while A10 is busy.

6. Optimistic locking

Instead of waiting, detect conflict. Each seat carries a version. Updates succeed only if the version you read is still current.

UPDATE seats
SET status = 'BOOKED', version = version + 1
WHERE seat_number = 'A10' AND version = 5;
-- 1 row updated → you won
-- 0 rows updated → someone else committed first

7. Don’t hold database locks during payment

Payment can take seconds to minutes. A row lock that spans payment becomes a throughput bug dressed as correctness.

8. Seat hold

A hold is a temporary reservation with an expiry — application state — not a multi-minute database lock.

9. API design

Two short write paths beat one long “book everything” request.

{
  "show_id": "show_123",
  "seat_ids": ["A10", "A11"]
}

→ {
  "hold_id": "hold_456",
  "status": "HELD",
  "expires_at": "2026-09-10T17:04:32Z"
}

{
  "payment_id": "payment_789",
  "status": "CAPTURED"
}

{
  "hold_id": "hold_456",
  "payment_id": "payment_789"
}

→ {
  "booking_id": "book_999",
  "status": "CONFIRMED"
}

10. Idempotency

Timeouts happen after the server already succeeded. Retries without an idempotency key create duplicate bookings — a different bug from seat races.

11. Database schema

Enough tables to tell the truth. Not a warehouse diagram.

12. Complete system

Click a component to see what it owns.

13. Cheat sheet

Race condition

Concurrent requests observe the same state and both act on it.

Pessimistic locking

Lock rows before modifying them.

SELECT FOR UPDATE

Row-level lock inside a transaction (e.g. PostgreSQL, MySQL/InnoDB).

Seat hold

Temporary reservation with expiry — not a long DB lock.

Idempotency

Repeated identical request yields the same result.

Transaction

Make critical state transitions atomic.

Payment

Happens outside the seat-row lock window.

Booking confirmation

Lock + validate hold + mark booked atomically.