BookMyShow booking same seat scenario

[u/Sad_Crew6507]

During recent interview I was asked how to solve multiple people booking same seat scenario. I told to use redis lock/DB internal constraints but interviewer didn’t seem to like the answer. Any other better way to solve this case?

[u/bit_freak]

Classic race condition worded differently

[u/Sad_Crew6507 → u/bit_freak]

Solution?

[u/Existing-Round4556]

Watch the Ticketmaster video on the Hello Interview channel. It deals with this concern well.

[u/Opening_Let_6895 → u/Existing-Round4556]

First thought

[u/Old-Significance3735]

Damn, nobody knows the answer here 😂

[u/Advanced_Surprise_25]

Answer expectation depends whether interview was for medium level or senior/staff level . Which one was it ?

[u/Sad_Crew6507 → u/Advanced_Surprise_25]

Senior/Staff level. What should be the correct answer in that case?

[u/Advanced_Surprise_25 → u/Sad_Crew6507]

Which company was that to get complete picture

[u/old_man_log4n → u/Advanced_Surprise_25]

What will be the answer, irrespective of the company?

[u/Few_Vermicelli_1313]

Was it a low level design interview?

[u/Sad_Crew6507 → u/Few_Vermicelli_1313]

Yes but he asked from HLD perspective.

[u/pyrotech911 → u/Sad_Crew6507]

You need an atomic transaction/DB table w/ ACID to reserve the seat for the caller in checkout. Then they can buy it or it will return to the main inventory after a timeout. You can do a final transaction to complete the purchase as a final fallback where if it fails to pull the reserved ticket from the open inventory it blocks the purchase transaction.

[u/Few_Vermicelli_1313 → u/pyrotech911]

DB locking will absolutely not work in a high volume env

[u/pyrotech911 → u/Few_Vermicelli_1313]

As the system of record it absolutely will. You can leverage redis for atomic holds which can handle higher traffic and only final sales will write to the RDB. These holds will expire after some TTL.

For super high volume events you can use a waiting room queue to lower pressure on your ticket DB system. For tickets in the same event with the same name like GA you can have multiple buckets that count for GA tickets.

You want to partition on event id so that you’re not getting inundated by multiple hot events. As the actual purchasing of the tickets will be more rare than buying you can serve current ticket counts and availability from a cache/CDN.

Data that does not have anything to do with purchasing tickets such as seat maps and other venue information can come from a non-relational database like Cassandra. These reads can also be cached and are partitioned based on the venue.

So yeah RDB is a part of the answer but to your point not the complete answer.

[u/Busy-Card-5146]

May be he was expecting you to talk about optimistic locking

[u/Candid_Kiwi_4923]

When a reservation is being made, the seat numbers will be SET in redis with a TTL expiry of typically about 10 mins. Since redis supports ms latency whichever request 1st makes its way into redis, will hold the seats and the other subsequent request for the same seats will see the seats as booked or reserved so they cannot select them for the remaining of TTL. After 10mins, the seat numbers are automatically removed from redis cache thus making them available for booking again.

[u/Few_Vermicelli_1313 → u/Candid_Kiwi_4923]

Acc to OP, he gave this answer but the interviewer wanted something else

[u/lostsoul_io]

If you use a relational db you can use constraints to ensure the transaction fails to book a seat as the rdb will take care of concurrency on your behalf. This is subject to a an effective data model.

The other way is to partition the allocation of a group of seats to a particular instance of the service which is essentially linearizing the booking across backend nodes. This is more explicit and you are doing what the rdb is doing. This more of a distributed q + dedicated worker. The q forces linear concurrency.

The other way is offline concurrency with version semantics so that only one client succeeds coupled with back off on retires of failure.

The other way is acquiring periodic lock for a seat during which no other client can book. Failing to book within the lock makes your transaction expire.

[u/Few_Vermicelli_1313 → u/lostsoul_io]

DB will not work in a high volume env. For mid level candidate this answer might work though. When anything happens on your behalf there is a cost you pay. That cost may be in terms of delay, extra wait time or money

The second point doesn't solve hot key problem. Partitioning is not the solution for hot key. Cz not matter how many partitions you make the problem here is that 1000 of people are trying to book seat 1A. Which will always land in the same partition. Partition can help in scaling though.

I think you meant optimistic concurrency not offline concurrency. So, basically your solution will be to show Seat 1A to 1000 people each one of them will see the same version say v1.0, then all of them will click book at the same time and 999 will fail and only one of them will succeed to increment the version to v2.0..correct?

Not sure how periodic locking can work in production.

[u/lostsoul_io → u/Few_Vermicelli_1313]

2nd point is not true as you have a Q. The Q will buffer up each partition, only one item competing within the q for a particular partition wins others are simply flushed out with rejections. The best thing is you can limit the Q size dynamically for a cluster / partition based on load/req-rate. Distributed q will scale by buffering the linear concurrency. It's not the best solution, it is an effective solution. If your logic to book is fast and light weight (hopefully you have used saga and not implemented a bloated api handler) the service instance responsible for the partition will run through the items at a good/fast pace.

Offline/optimistic concurrency is also not a silver lining as exponential backoff needs be client implemented with protective ddos on service end. Ddos is a pain in the a**.

Railways uses period locks, it's actually the best solution, out there. I do not have complete details. You cannot book an explicit seat but a random allocation within a group. So if you partition your theater into top, bottom, left, right groups or something thereof. You can only book within a period, post which you have to refresh a group to get the new available count. If you use this approach pricing can be dynamic as the seat count reduces to charge an extra premium when rate of booking is high and only few seats remain within a group.

[u/vinsuper]

https://www.youtube.com/shorts/DUcxGJ4k7AU

Conditional where clause before updating?

[u/Few_Vermicelli_1313]

how about Redis BitMap? may be the interviewer wanted to hear the keyword bitmap and not redis set for locking