1. Extreme Flash Demand & Bot Mitigation
When a global superstar announces a stadium tour, millions of concurrent users hit the site the second tickets go live. The ratio of buyers to seats can exceed 200:1. The system must prevent scalper bots, ensure fair distribution, and guarantee that no two fans can buy the exact same seat.
2. Virtual Waiting Room (Queue-It Architecture)
Users entering the site before the on-sale time are placed in a pre-queue pool. At the designated second, the pool is randomized to neutralize bots with microsecond advantage.
A token bucket controller admits users into the active seat selection portal in controlled batches of 1,000 per second, matching backend transactional capacity.
3. Seat Selection State Machine & Distributed TTL Lock
A seat exists in one of four states: AVAILABLE -> TEMPORARILY_HELD -> BOOKED -> (or back to AVAILABLE if checkout expires).
When a user selects seats on an interactive SVG seat map, the application executes a Redis `SETNX` lock on `seat:{venue_id}:{seat_id}` with a 10-minute lease. If the user completes payment, the seat transitions to BOOKED in the primary database; if the timer expires, Redis keyspace notifications release the seat.
4. Database Partitioning by Event & Venue
Ticketing data naturally partitions by `event_id`. Each major concert runs on its own database shard or dedicated tenant database, preventing high load on one concert from impacting sales for unrelated events.
Model this architecture on the HLDForge Canvas
Turn static box diagrams into living, collaborative systems. Drag and drop microservices, Kafka clusters, and cache tiers. Run automated SPOF detection and STRIDE threat modeling in real time.
Written by HLDForge Architecture Team
Principal Systems Architect
The HLDForge Architecture Team publishes practical engineering guides, real-world case studies, and high-concurrency blueprints to help engineers build scalable and fault-tolerant software.