Design Ticket Booking

Зачем нужно знать

Ticket booking похож на hotel booking только на поверхности. В гостиницах contention обычно распределен по отелям, датам и room types. В ticketing вся нагрузка может ударить в один event в одну минуту: миллионы пользователей хотят 80K мест, и большинство неизбежно проиграет. Поэтому задача системы не “продать всем”, а честно, предсказуемо и без oversell распределить ограниченный inventory под экстремальным burst.

Целевой workload — сценарий, а не claim о конкретном операторе: 100K active events, 500M seat records, steady browse 5K RPS и modeled flash burst до 2M RPS. Hold attempts могут кратковременно превысить core capacity на порядки, но request rate нельзя делить на 80K seats и называть “oversubscription ratio”: это разные единицы. Admission limits выводятся из измеренной capacity и active-session budget.

Кейс тренирует [CONCEPT]rate-limiting-algorithms, [CASE]cdn-design, [CONCEPT]idempotency и [CONCEPT]database-internals-overview. Если hotel booking учит короткому hold на inventory, ticket booking добавляет waiting room, антибот защиту и stale real-time seat map.

Mental model

Думайте о ticket booking как о funnel с intentional shedding. Waiting Room использует явную FIFO/random policy и лимиты active sessions/new users per minute. Signed admission token привязан к event, account/session, nonce и expiry и проверяется на каждом mutating endpoint. Это load shaping и policy boundary, а не математическая гарантия идеальной fairness.

Второй mental model: Postgres является source of truth и для temporary hold, и для booked seat. Redis SET NX с random token — только burst prefilter: после него короткая PG transaction переводит seat available -> held, связывает его с durable seat_hold и expiry. Поэтому cache miss не может re-hold уже booked seat, а Redis failover не забывает право текущего owner-а. Если Postgres недоступен, новые holds останавливаются fail closed.