Design Ticket Booking Auto Release evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
##### Question
Design a ticket-booking system where a reserved ticket automatically returns to the inventory if payment is not completed within 30 minutes. Discuss data model, reservation flow, concurrency handling, timeout processing, and consistency guarantees.
Quick Answer: Design Ticket Booking Auto Release evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Design a ticket-booking system where a reserved ticket automatically returns to the inventory if payment is not completed within 30 minutes.
Discuss and propose a design for:
Data model and state machine.
Reservation and payment flow.
Concurrency control to prevent overselling.
Timeout processing (auto-expiry) at scale.
Consistency guarantees and failure handling.
Assumptions
Tickets can be either seat-based (assigned seats) or general admission (GA) with a capacity count.
A reservation places a temporary hold for 30 minutes. If payment is completed within that window, the reservation becomes a purchase; otherwise, it expires and inventory is released.
High read/write throughput; horizontally scalable services.
Payment is processed by an external provider and can succeed/timeout/arrive late.
Clarifying Questions to Ask Guidance
Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.
What a Strong Answer Covers Guidance
A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.
Follow-up Questions Guidance
What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?