Problem Statement
Design a bus booking system similar to RedBus. Users should be able to search for buses by source, destination, and time, then book seats. The system must handle concurrent bookings safely.
Requirements
Functional:
- Search buses by source, destination, date/time
- View available seats for a bus
- Book one or more seats
- Handle payment and confirmation
- Send booking notifications
Non-Functional:
- Two users must NOT be able to book the same seat simultaneously
- Search should be fast
- Reliable notifications
What the Interviewer Expects
- Search design — index buses by (source, destination, date). Discuss how to efficiently query routes and available seats.
- Seat booking concurrency (the key focus):
- The classic problem: two users select the same seat at the same time
- Pessimistic locking: lock the seat row during booking (SELECT FOR UPDATE)
- Optimistic locking: version/status check — seat has a status (available/locked/booked); use atomic compare-and-set
- Temporary hold: lock the seat for N minutes during payment, release if payment fails
- Data model — buses, routes, schedules, seats, bookings, users tables.
- Notification system — async via message queue (booking confirmation, reminders). Decouple from the booking flow.
- Payment flow — hold seat → process payment → confirm or release on timeout.
Follow-ups
- How do you handle a seat held during payment when the user abandons checkout?
- How would you prevent overselling during high-demand routes (festival season)?
- How would you design the notification system to be reliable (at-least-once delivery)?
- How do you scale search for millions of routes and queries?
- How would you handle dynamic pricing based on demand?