Ticketing System: Low-Level Design – Tech Interview Dot Org

A ticketing system (like Ticketmaster for concerts, or an airline seat booking system) manages limited inventory under simultaneous high demand. The core challenge is preventing oversell — two users booking the same seat simultaneously — while maintaining responsiveness during traffic spikes (ticket drops for popular events can generate 1M+ concurrent requests in seconds).

Inventory Reservation Problem

The fundamental problem: prevent two users from simultaneously reserving the same ticket. Naive approach: SELECT available seats, present to user, INSERT reservation on confirm — vulnerable to race conditions (both users select seat A, both confirm before either insert). Solution: use pessimistic locking (SELECT … FOR UPDATE) or optimistic locking (version numbers with conditional update) to serialize conflicting reservations at the database level.

Two-Phase Reservation with Expiry

A good UX allows users to hold tickets in a cart for a period (15 minutes) before payment. Design: (1) Hold/Reserve phase: when a user selects tickets, temporarily reserve them by marking as status=held, held_by=user_id, held_until=now+15min. This is done atomically — UPDATE seats SET status=held WHERE id=? AND status=available; the affected row count tells you if the update succeeded (1) or not (0 — someone else already held it). (2) Confirm/Purchase phase: when the user completes payment, UPDATE seats SET status=sold WHERE id=? AND status=held AND held_by=? AND held_until>now. (3) Expiry: a background job periodically runs UPDATE seats SET status=available WHERE status=held AND held_until<now, releasing seats whose hold expired.

Handling Traffic Spikes

Popular ticket drops (Taylor Swift, Super Bowl) generate 1M+ concurrent requests the instant tickets go on sale. This crushes any database that isn’t specifically designed for it. Approaches: (1) Virtual queue: redirect users to a waiting room (random or FIFO queue); release them to the booking flow in batches at a rate the backend can handle. Ticketmaster uses this. (2) Inventory in Redis: move inventory management to Redis using atomic operations (DECRBY, SETNX). Redis can handle 1M operations/second; the database is only written at the confirmation step. (3) Horizontal scaling with rate limiting: scale the API tier horizontally; rate limit per user to prevent any one user from holding excessive inventory.

Redis-Based Inventory

To handle high-concurrency ticket availability checks and reservations: store available_count per event in Redis. On reserve: use a Lua script (atomic) to check available_count > 0, decrement, and record the reservation in a Redis hash. If Redis is the source of truth for availability, the database is only updated asynchronously for durability. Lua script atomicity prevents race conditions: the check and decrement happen in a single Redis operation. If the Lua script returns 0 (no tickets available), immediately return “sold out” without touching the database. This reduces database write load from 1M concurrent requests to the rate of successful reservations (typically much lower).

Payment Integration

Payment must complete within the hold window (15 minutes). If payment fails, release the hold immediately so other users can purchase. If payment processing times out (no response from payment provider within 30 seconds), enter a “pending payment” state — do not release the hold yet. A reconciliation job checks pending payments with the payment provider and resolves: if the provider confirms the charge, mark as sold; if the provider shows no charge, release the hold. This handles the case where the user’s payment succeeded but the webhook was delayed or lost.