3

I am trying to build a movie ticketing system. But I am not able to figure out how to solve the below use case:

  • Let’s say there are 10 seats namely S1,S2,S3,S4… S10.

  • Now let’s say that User1 had logged into the system and selected seats S1 and S2.

  • Both these seats must be automatically blocked for a time span of 15minutes; so that the User1 can make payment within this time and confirm the seats.

  • Meanwhile if another User2 logs into the system, the seats S1 and S2 must be viewed as blocked.

  • The seats will be unblocked only if the 15minutes time out occurs (or) The User1 willingly aborts the booking process.

Any idea how to achieve this? Can we do this blocking and unblocking asynchronously by avoiding page reloading?

I have already searched for solutions and found this related question: How do I handle the potential concurrency problem of making a payment to Paypal for a limited number of items?

But it didn't help me. I am sure I have to take the item off the shelf for sometime. But technically how to achieve this? should i update the database to make that seat as blocked? if i did so, how to unblock it upon failure or if the user abandons the system? How to update the UI asynchronously ?

0

The challenge for the movie ticketing is the contention that peaks as the movie start time approaches.

Two parts are time consuming: the choice ( and some people don't even care as long as they are next to each other), and the paiement (which is often processed by external webservices). So you could improve the situation by chosing one of the following option:

Option 1: realtime locking approach

Make locking much shorter (e.g. 2 minutes), but allow the session to extend it every time the user is active (mouse and keyboard events). This would even be nicer if the user selection screen would reflect the changes in seat status.

Option 2: the optimist's approach

Be optimist. Make no locking and explain it's first come first served, and book the seat at the end of the payment. If the desired seats are no longer available, propose a new choice (but no payment is needed: it can be booked immediately) or a refund (I assume the payment is done on an external system and that you can't influence its transaction management).

This might however be upsetting for the user if there are only a few places left or if they just don't care about the seat location.

Option 3: the airline approach

It's a variant of the optimist approach, that steeply reduces the stress for the users: Ask for how many seats, and what's the preferred area (e.g. front, middle or back). Verify availability, make the payment, the booking will then book the consecutive seats, if possible in the preferred area or elsewhere if not. Inform the user of his booked places and allow to chose other seats if not happy.

This works best when most of the people don't want a very specific seat, leaving your system optimizing the allocation while minimizing the locking.

How to do it technically ?

You didn't give much technical information about your project, so it will be difficult to help. An possible approach could be to flag the seats as temporarily booked, using the session id, and cancel the related booking if session expired (option 1). Another approach would be to use transactional management of the database (option 2 and 3): a failure to complete the transaction shows that another session already acquired the seat.

| improve this answer | |
  • 1
    I don't disagree with the technical content of this answer but doesn't the airline approach require a backup of armed thugs to drag old people and children out of their seats when overbooked ? I guess that would be step 4 ... – High Performance Mark Aug 19 '17 at 11:32
  • 1
    @HighPerformanceMark :-D ! You made my day! you definitively shouldn't envisage overbooking if you don't want a riot in the theatre ! Overbooking is a deliberate business choice not a technical consequence – Christophe Aug 19 '17 at 11:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.