zlacker

I have been asked this question in interviews for how to prevent two people from booking the same seat. Interviewers don’t seem to be satisfied by the answer that I will let the query go to the database and see who ends up booking. They want some advanced locking mechanism using redis. Redis does serialize queries using lua thus avoiding two people from booking the same seat.

>>abhish+(OP)
based on experience arriving very last minute to flight, nobody has problem with letting two people book the same seat.

>>abhish+(OP)
I think this being a good answer hinges on the resulting user experience. If one person spends several minutes going through the process of putting in their payment and other info only to be told you don't have a ticket, they're going to be pissed. So you need a good answer on how to avoid that experience, however you implement the locking.

Saying this as someone who has been on both sides of that interview question, and also evaluated performance in it as a hiring manager.

>>bryanr+44
Let the check-in attendant handle it; that's what I call a no-code solution! You're hired

>>agf+54
Send bookings to the database early, with an expiry time and a counter visible on the screen?

Thing is, because purchasing is often shared across third-parties, even then you can’t guarantee that you’ll have the reservation until it’s paid and entered into the shared booking backend… unless the third party backend has a locking mechanism, at which point you’re probably not using your own Postgres to do this, but their mainframe instead.

>>kyleee+B9
That's solid middle management thinking right there!

>>agf+54
Is there any other solution other than going full STM on this?

>>bryanr+44
mmmm no

They allow overbooking the flight but you can't book the same seat twice.

Overbooking can make financial sense -- even if you need to hand a little compensation from time to time it's still better than flying with empty seats. Of course it sucks big time for the travelers especially if there are no volunteers. IDB is miserable. https://www.transportation.gov/individuals/aviation-consumer...

>>abhish+(OP)
I had a similar question asked of me in an interview. The interviewer was also surprised by my solution of letting the database decide the winner.

>>chx+ly
They obviously don't have the transaction semantics worked out. I have been at the gate and the person in front of me had the same seat number. They read it out. When I presented my pass the girl politely took my ticket and printed another one. If the person was not right in front of me I would never have known why. It is not unusual.

>>chx+ly
>They allow overbooking the flight but you can't book the same seat twice.

ok, but how do you overbook a flight without booking at least one of the seats twice?

>>kyleee+B9
Reminds me of Starbucks does not use two phase commit. https://news.ycombinator.com/item?id=6229004

>>bryanr+yV
You don't assign all the seats up front. Some are marked to be assigned at the gate.

>>spockz+Bp
Yes a simple SCRM will do.

>>kccqzy+By
What exactly is the right answer here?

>>agf+54
So what do you propose here? I see that stackoverflow mentions some preemptive locking for a seat in cache for a few minutes. During that time the seat is taken out of the pool for potential booking. If the time lapses without the seat getting booked then the seat returns to the pool. This avoids going to the DB and see who wins.

>>mathfa+ya1
What is SCRM?

>>bryanr+44
Well, sure. But what if you want to avoid such a scenario? Two people booking vaccine slots shouldn’t be allowed the exact same slot. They are going to be pissed realising one of them reached the center but didn’t get the vaccine.

>>kyleee+B9
Wouldn’t the attendant be in trouble if two people at the gate start fighting for the same window seat as printed on their ticket?

>>Jailbi+j31
Well then the problem moves a little to the left. If there are x seats to be booked up front and y seats to be allocated later. How many times can each of the x seats be booked and how do you prevent that n and n+1 over the limit booking for some seat? The problem is still there.

>>abhish+(OP)
The "what actually happens" answer is often "let them both book successfully and then rebook the person with lower loyalty status".

>>abhish+k12
Airlines have been data mining for a very, very long time now and have a reasonably guess of the ratio of people booking vs showing up at the gate to fly. So you set your buckets to oversell by that much and assign seats later. If more people show up than expected than you throw them a voucher to go away. Hopefully enough will.

Sometimes it doesn't work out and that's when airlines bleed. I was flying home one day from some US city (was it Denver? the years and cities blend together) when a Drupal conference and some major sports thing ended the same day and the airport was a total gong show. United first offered a paltry 120 USD but when they raised to 400 USD to go home the next day instead my hand went up -- and I was such a greenhorn I didn't know they will pay for the hotel, too. A buddy pocketed no less than 1200 USD from Delta.

>>chx+l76
This looks like one solution but I don’t think you want this design in medicine slot booking or stock selling. You want it to be much more definite if there is no way for a conflict to be resolved. This solution won’t work there.