Loading LLD design...
Design an object-oriented concert ticket booking system that manages venues with sectioned seat maps (VIP, Premium, Regular, Standing), event scheduling with per-type pricing, a temporary seat-hold mechanism with configurable timeout, payment processing, and booking confirmation.
Seats transition through AVAILABLE → HELD → BOOKED (or back to AVAILABLE on expiry/cancellation). Bookings follow a lifecycle: PENDING (seats held) → CONFIRMED (payment received) or EXPIRED/CANCELLED. The system supports event cancellation with bulk refunds and a background sweep to expire stale holds.
Create venues with seat maps
Register venues with sections and seats (VIP, Premium, Regular, Standing)
Schedule events
Create events at a venue with per-type pricing and sales status
Search events
Search by name, artist, date, or city
View available seats
Browse available seats for an event, optionally filtered by type
Hold seats (temporary lock)
Temporarily hold selected seats for a configurable duration (10 min)
Confirm booking with payment
Process payment and confirm the booking within the hold window
Cancel booking and refund
Cancel a booking, release seats, and refund the payment
Expire stale holds
Background sweep to expire bookings whose hold timer has elapsed
Cancel event
Cancel an event and refund all associated bookings
Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.
Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.
Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.
What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.
What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.