hard general · part of Practice Questions · Senior SWE Roadmap
Requirements to clarify
- Functional: browse available seats/rooms, hold a selection temporarily, complete payment to confirm, release the hold if payment isn’t completed in time.
- Non-functional: must never oversell/double-book, must handle high concurrent demand for popular events (many users trying to book the same seat simultaneously).
Core components
- Inventory locking: when a user selects a seat, place a short-lived lock/hold (e.g., a TTL-based reservation in a fast store) so no one else can select it while checkout is in progress.
- Concurrency control: use a database-level mechanism (optimistic locking with a version check, or a
SELECT ... FOR UPDATEstyle pessimistic lock) to guarantee only one booking wins if two requests race for the same seat. - Expiration/cleanup: a background job or TTL mechanism releases holds that aren’t converted to a confirmed booking within the time limit.
- Payment integration: the booking is only finalized after payment succeeds — idempotency keys prevent double-charging on retry.
Key tradeoffs
- Pessimistic locking is simpler to reason about but can hurt throughput under very high contention (popular on-sale events); optimistic locking scales better but needs a clear retry/conflict UX for the loser.