Picture two people booking the last seat at a concert the moment tickets go on sale. Both search at the same instant. Both see 1 seat available. Both click "Buy Now." Without careful coordination, the system confirms both purchases, charges both cards, and generates two tickets with the same seat number — and one very unhappy person at the gate. This is the **double-booking problem** — a specific form of the lost update race condition applied to finite inventory. Unlike a bank overdraft which can be caught and reversed, a double-booked seat at a sold-out show or a walk-in guest at a fully occupied hotel has no invisible recovery path. You either turn someone away, or you absorb the cost of a last-minute fix. The root cause is the same as every race condition: a **read-check-write** cycle that is not atomic. The gap between checking availability and committing the reservation creates a window where another request can invalidate your assumption. Every strategy in this article closes that window in a different way. ## The Two-Layer Inventory Model Before choosing a concurrency strategy, the data model must be right. Every large reservation platform — Booking.com, Airbnb, Ticketmaster — separates inventory into two distinct layers. **The supply layer** holds what guests or buyers search against. For hotels this is a `room_type` (Deluxe King, Standard Twin) plus a per-day `availability_slot` tracking a unit counter. For ticketing it is the `seat` row itself. This layer answers: *how many units are available?* **The assignment layer** holds the specific physical unit — Room 101, Seat G14. In hotels, assignment is deferred to check-in. In ticketing, the exact seat is chosen at booking time. The separation matters because it determines where you place your concurrency controls. ``` Hotel / OTA model room_type → availability_slot (units_total, units_booked) → reservation ↓ at check-in physical_room Ticketing model venue → section → seat (status: available | held | sold) → order_item ``` The hotel model manages a **count** — you don't care which specific room until check-in. The ticketing model manages **individual unit state** — every seat is either available or it isn't. These two shapes require different concurrency strategies. ## The Availability Check Query For both models, the check query answers one question: is there at least one free unit for this request? For the hotel model: ```sql SELECT COUNT(*) AS nights_available FROM availability_slot WHERE room_type_id = :room_type_id AND date >= :check_in AND date < :check_out -- check-out night is not a stay night AND status = 'open' AND (units_total - units_booked) >= 1; ``` If `nights_available` equals the number of requested nights, the room type is fully open. For ticketing: ```sql SELECT id, section_id, row_number, seat_number FROM seat WHERE event_id = :event_id AND section_id = :section_id AND status = 'available' LIMIT :quantity; ``` **This query alone is never safe to act on.** It is a read without a lock. By the time your application reaches the write, another transaction may have taken the last unit. The check is useful for search results pages — showing counts to browsing users — but must never be the sole gate on a booking write. ## Pessimistic Locking: The Safe Default Pessimistic locking prevents the race entirely by acquiring an exclusive lock on the relevant rows before checking counts. Any concurrent transaction touching the same rows blocks until the first one commits or rolls back. ```sql BEGIN; -- Lock the slot rows for this date range. -- ORDER BY date prevents deadlocks from inconsistent lock acquisition order. SELECT id, units_total, units_booked FROM availability_slot WHERE room_type_id = :room_type_id AND date >= :check_in AND date < :check_out ORDER BY date FOR UPDATE; -- Re-validate INSIDE the lock -- the search result the user saw may be stale. -- If any night shows (units_total - units_booked) < 1 → ROLLBACK INSERT INTO reservation (id, room_type_id, guest_id, check_in, check_out, status, total_price) VALUES (:res_id, :room_type_id, :guest_id, :check_in, :check_out, 'confirmed', :total); -- One row per night: enables per-night pricing and partial cancellations INSERT INTO reservation_item (id, reservation_id, date, price) SELECT gen_random_uuid(), :res_id, a.date, COALESCE(a.price_override, rt.base_price) FROM availability_slot a JOIN room_type rt ON rt.id = a.room_type_id WHERE a.room_type_id = :room_type_id AND a.date >= :check_in AND a.date < :check_out; -- Atomically increment the booked counter on each slot row UPDATE availability_slot SET units_booked = units_booked + 1 WHERE room_type_id = :room_type_id AND date >= :check_in AND date < :check_out; COMMIT; -- Locks released. The next queued request now sees the updated counter. ``` The `ORDER BY date` on the `FOR UPDATE` clause is not cosmetic. Without it, two concurrent transactions can lock the same rows in opposite orders — Transaction A locks Jan 5 then Jan 6, Transaction B locks Jan 6 then Jan 5 — and deadlock. Consistent acquisition order eliminates this class of bug entirely. **When it works well:** Any scenario where the same inventory is contested by many concurrent requests — hotel peak season, flash sales, venue on-sales. The lock hold time is short (one database round trip for the writes), so throughput remains acceptable. **When it breaks down:** If payment processing runs inside the same transaction, the lock is held for the full duration of the payment API call — often several seconds. Other requests queue up behind the lock holder and time out. Move payment outside the transaction window. The lock should only cover the inventory read and write, nothing else. **See it in practice:** In [Ticket Master](/learn/system-design/questions/ticket-master), seat status transitions use `FOR UPDATE` to serialize competing buyers on the same seat row. In [Hotel Booking](/learn/system-design/questions/hotel-booking), the `availability_slot` counter increment uses the same pattern across a multi-night date range. The [Dealing with Contention](/learn/system-design/design-patterns/locking-concurrency-control) pattern covers `SELECT FOR UPDATE` semantics, deadlock detection, and lock wait timeout behavior. ## The Seat-Hold Pattern For high-demand events — concert on-sales, sports playoffs — you cannot hold a database lock while the user fills in payment details. The lock would be held for minutes, blocking every other buyer in a long serialized queue. The solution is a **seat hold**: a time-limited reservation that takes the seat out of available inventory without committing the purchase. If payment completes within the window, the hold converts to a confirmed booking. If it expires or the user abandons, the seat returns to available inventory automatically. The hold acquisition uses a conditional update — no explicit lock required: ```sql -- Transition: available → held (atomic compare-and-swap guard) UPDATE seat SET status = 'held', held_by = :session_id, held_until = NOW() + INTERVAL '10 minutes' WHERE id = :seat_id AND status = 'available'; -- only succeeds if nobody else got here first -- 1 row affected → hold succeeded, proceed to checkout -- 0 rows affected → seat already taken, return error to user ``` On payment completion: ```sql UPDATE seat SET status = 'sold', order_id = :order_id, held_by = NULL, held_until = NULL WHERE id = :seat_id AND held_by = :session_id -- only the holder can convert to sold AND held_until > NOW(); -- expired holds cannot be converted ``` Expiry is handled by a background job: ```sql UPDATE seat SET status = 'available', held_by = NULL, held_until = NULL WHERE status = 'held' AND held_until < NOW(); ``` **When it works well:** Any system where inventory is discrete and the buy flow spans multiple steps. The hold gives users time to complete payment without holding a database lock for the entire duration. **When it breaks down:** When demand dramatically exceeds supply, aggressive hold TTLs make the experience feel unfair — a seat appears available, the user adds it to cart, and it vanishes before checkout because another user's hold is still live. Ticketmaster layers a virtual waiting room on top of seat holds precisely because the hold pattern alone breaks down at that scale. **See it in practice:** In [Ticket Master](/learn/system-design/questions/ticket-master), seat holds with a 10-minute TTL are the core of the checkout flow. In [Airbnb](/learn/system-design/questions/airbnb), a "request to book" intermediate state holds inventory while the host approves. The [Managing Long-Running Tasks](/learn/system-design/design-patterns/managing-long-running-tasks) pattern covers TTL-based state machines and background expiry workers. ## Optimistic Concurrency: When Contention Is Low For properties with large supply relative to demand — a 200-room hotel on a slow Tuesday — the probability of two users racing on the exact same room type and date is low. Pessimistic locking adds overhead that is rarely justified. Optimistic concurrency avoids locks entirely and only pays a retry cost on the rare actual collision. Add a `version` column to `availability_slot` and include it in every update's `WHERE` clause: ```sql -- 1. Read slots and note versions SELECT id, units_total, units_booked, version FROM availability_slot WHERE room_type_id = :room_type_id AND date >= :check_in AND date < :check_out; -- 2. Attempt the update -- fails silently if any row changed since the read UPDATE availability_slot SET units_booked = units_booked + 1, version = version + 1 WHERE room_type_id = :room_type_id AND date >= :check_in AND date < :check_out AND version = :expected_version; -- 3. Affected rows < nights_count → conflict → re-read and retry ``` **When it works well:** Long-tail inventory, off-peak travel, large apartment complexes. Any case where two buyers targeting the same unit at the same moment is statistically unlikely. **When it breaks down:** Flash sales and on-sales. When thousands of requests simultaneously target the same `availability_slot` row, nearly every write fails and retries. The retry storm burns more CPU than pessimistic locking would have, and perceived latency spikes across the board. **See it in practice:** The [Dealing with Contention](/learn/system-design/design-patterns/locking-concurrency-control) pattern covers the full optimistic vs pessimistic trade-off and explains how retry storms emerge under high contention. In [Google Calendar](/learn/system-design/questions/google-calendar), overlapping event creation uses version checks because conflicts are genuinely rare in calendar scheduling. ## Guarantee the Same Room Across All Nights The room-type model means guests search by type, not by room number. When the system auto-assigns, it must pick **one physical room and confirm it across the entire stay**. The dangerous anti-pattern assigns rooms independently per night: ```sql -- WRONG: may assign Room 101 on Monday, Room 203 on Tuesday SELECT date, MIN(physical_room_id) AS room_id FROM availability_slot WHERE room_type_id = :type_id AND status = 'open' GROUP BY date; ``` The correct approach finds one room that is free on every night before touching any data: ```sql -- Find one physical room available on ALL nights in the range SELECT a.physical_room_id FROM availability_slot a WHERE a.room_type_id = :room_type_id AND a.date >= :check_in AND a.date < :check_out AND a.status = 'open' AND (a.units_total - a.units_booked) >= 1 GROUP BY a.physical_room_id HAVING COUNT(*) = :nights_count -- free on EVERY night LIMIT 1; -- Feed this single room_id into the FOR UPDATE booking transaction ``` ## Cancellation: Releasing Inventory Cleanly Cancellation is the inverse operation. Because `reservation_item` stores one row per night, partial cancellations are surgical — only the cancelled nights return their unit to the available pool: ```sql BEGIN; UPDATE availability_slot AS a SET units_booked = units_booked - 1 FROM reservation_item ri WHERE a.room_type_id = :room_type_id AND a.date = ri.date AND ri.reservation_id = :reservation_id AND ri.date BETWEEN :cancel_from AND :cancel_to; UPDATE reservation SET status = 'cancelled' WHERE id = :reservation_id; COMMIT; ``` Never delete `reservation_item` rows on cancellation. Mark them cancelled and adjust the slot counter. These rows are your audit trail — refund calculations, dispute resolution, and revenue reporting all depend on them. ## The Virtual Waiting Room: Queue-Based Serialization for Peak Demand For extremely high-demand moments — a major artist's tour on sale, a championship game — even pessimistic locking becomes a bottleneck. Millions of requests hit the same inventory rows in the same second. Lock wait times spike and requests time out before they reach the write. The solution is a **virtual waiting room**: requests are queued before they ever touch inventory. A token bucket admits a controlled number per second. Each admitted request gets a window to complete the purchase. Everyone else waits with a live position counter. ``` Incoming requests → Redis queue (keyed by event_id) ↓ Token bucket rate admission ↓ Checkout with seat hold (10 min TTL) ↓ Inventory write (FOR UPDATE) ``` This moves contention upstream. The inventory layer still uses `FOR UPDATE`, but it sees a controlled trickle rather than millions of simultaneous requests. Lock contention at the database collapses to near zero. **See it in practice:** In [Ticket Master](/learn/system-design/questions/ticket-master), the virtual waiting room is the primary scaling mechanism for high-demand on-sales — demand can be 500x supply in the first second. The [Dealing with Contention](/learn/system-design/design-patterns/locking-concurrency-control) pattern covers queue-based serialization using Kafka partitions as a general primitive. The [Rate Limiting](/learn/system-design/design-patterns/rate-limiting) pattern covers token bucket admission and controlled queue drain mechanics. ## Trade-off Comparison ## Indexes That Make This Fast The availability check and slot update both filter on `(room_type_id, date)` or `(event_id, status)`. Without compound indexes, every booking transaction triggers a sequential scan — catastrophic under load. ```sql -- Hotel / OTA model CREATE INDEX idx_slot_type_date ON availability_slot (room_type_id, date); CREATE INDEX idx_res_type_dates ON reservation (room_type_id, check_in, check_out); CREATE INDEX idx_res_item ON reservation_item (reservation_id, date); -- Ticketing model CREATE INDEX idx_seat_event_status ON seat (event_id, status) WHERE status = 'available'; -- partial index: sold/held rows never scanned CREATE INDEX idx_seat_hold_expiry ON seat (held_until) WHERE status = 'held'; -- background expiry job only touches held rows ``` **See it in practice:** In [Hotel Booking](/learn/system-design/questions/hotel-booking), the `availability_slot` compound index is the single biggest factor in keeping availability queries under 10ms at load. The [Scaling Reads](/learn/system-design/design-patterns/scaling-reads) pattern covers read replica routing for availability search vs primary routing for booking writes, and how stale replica data can mislead users into dead-end booking attempts.