CareerCup

Basic design is to let database handle everything
You can design the backend in following ways

API -> GetListOfCities() - will go to DB and fetch list of cities into City Class
API -> GetListOfEventsByCity(CityId) - when user select city, this API will return a list of events in Event Class, which can be extended into multiple types of events such as movies, shows, or festivals etc.
API -> GetLocationsByCity(CityId) - This api will return list of locations(theaters, event grounds etc) based upon the city chosen by the user.
API -> GetLocationsByEventandCity(cityid, eventid) - when user select event, we know the eventid and we already know the cityid, we can make this API call to get locations where the event is getting played/organized.
API -> GetEventsByLocationandCity(CityId, LocationId) - this API will return list of events given the locationid and the city id, we are using cityid here to not create different locationid for same theaters in multiple cities.
API -> GetShowTiming(eventid,locationid) - when user select the location, we know the locationid, system will call this API to get the available show timings
API - > GetAvailableSeats(eventid,locationid,showtimeid) - user will select the showtime, and UI will let user select number of seats in next page, we call this API when user has selected the seat count, until this point everything was read-only, so no issue with concurrent calls, but from this point, we have the concurrency issue. this API will only show currently available seats, which can change in future, once the user has selected the seats, we will call this new API
API -> VarifyUserSelectedSeatsAvailable(eventid,locationid,showtimeid,seats) - this will tell us whether all the chosen seats are available or not, if not, we call GetAvailableSeats again for new available seats.
Once VarifyUserSelectedSeatsAvailable passes, we will block those seats for the user, and move the call to the payment gateway. if payment is failed for whatever reason, we will let the user do one more try, and then unblock those seats if not successful.

We will use SQL database in the backend,

City Table
{
    CityId
    Name
    Other properties if needed
}

Event Table
{
    EventId
    Event Name
    Other properties if needed
}

Location Table
{
     LocationId
     Location Name // like theater name
     Other properties if needed
}

ShowTime Table
{
     ShowTimeId
     ShowTime other details
}

CityEventLocation Table
{
     CityEventLocationID
     CityId
     LocationId
     EventId
     Custom Properties if needed
}

EventShowTime Table
{
     EventShowId
     CityEventLocationID
     ShowTimeId
     Custom Details specific to show times of the cityeventlocationid
}

Seats details are not stored with bookmyshow, once, they have showtime details, they will call custom apis provided by the theaters to get the seats current status.
If they don't have APIs, then, they have two solutions
one is that they manually call those theaters to book the tickets, other would be to save seats details in bookmyshow only and let those theaters book seats based upon bookmyshow page availability, (like, bookmyshow can provide admin page to those theaters to book windows tickets using admin page of bookmyshow only).

Movie: Id (Primary Key), title, directory, cast, description, running time

Screen: Id (PK), movie_id (FK (Movie)), theater_id (FK (Theater))

Theater: Id (PK), name, city, state, address, number_of_seats

Seat: Id (PK), Row_Number, Seat_Number, Theater_Id (FK (Theater))

Reserved_Seat: Id (PK), Seat_Id (FK (Seat)), Screen_ID (FK (Screen)), Theater_Id (FK (Theater))

Reservation: Id (PK), Screen_id (FK (Screen)), Reservation_Type (O - Online, W - Window, P - Promotional), Contact, Reserved (Y/N), Payment (Y/N/P (pending)), Active (Y/N)

Here are bunch of API calls

findAll(cities)

findAll(movies)

findMoviesByCity(selected_city)

findTheatersByMovie(selected_movie, selected_city)

findShowtimeByTheater(selected_theater, selected_movie, selected_city)

findAvailableSeats(selected_time,selected_theater, selected_movie, selected_city)

showPrice(selected_seat, selected_time,selected_theater, selected_movie, selected_city)

payForTickets(price, credit_card_details)

bookTickets(selected_seat, selected_time,selected_theater, selected_movie, selected_city, payment_successful_flag)

Regarding concurrent requests, we would need to block the tickets for x min while user is selecting the tickets. This will make sure that there is no double booking. This blocking will only happen when user selects the seats. The finder method calls will give state at the moment when request was invoked with a disclaimer that the state may change and actual state will be displayed at the time of seat booking.
Regarding scalability, the system can be scaled to any number and we can ask qualifying question as what interviewer expects to happen on scalability, whether its regarding supporting multiple vendors or multiple end users. Since our system is micro-service driven each service can work independently and stateless

write following API calls

findAllCities()

findMoviesByCity(selected_city)

findTheatersByMovie(selected_movie, selected_city)

findShowtimesByTheater(selected_theater,selected_movie, selected_city)

findSeatsByShowtime(selected_showtime,selected_theater,selected_movie, selected_city)

findPriceBySeat(selected_seats,selected_showtime,selected_theater,selected_movie, selected_city)

applyLockOnSeats(selected_seats,selected_showtime,selected_theater,selected_movie, selected_city, timestamp)

payForTickets(credit_card_info)

releaseLockOnSeats(selected_seats,selected_showtime,selected_theater,selected_movie, selected_city, timestamp)

bookTicket(selected_seats,selected_showtime,selected_theater,selected_movie, selected_city, user_info)

Regarding concurrent booking, we can run applyLockOnSeats and payForTickets in single transaction and put a lock on seats for x duration

Can anyone post the working solution

f