zlacker

[parent] [thread] 5 comments
1. agf+(OP)[view] [source] 2021-06-12 15:25:22
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.

replies(3): >>lstamo+s7 >>spockz+wl >>abhish+jW1
2. lstamo+s7[view] [source] 2021-06-12 16:35:57
>>agf+(OP)
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.

3. spockz+wl[view] [source] 2021-06-12 18:23:32
>>agf+(OP)
Is there any other solution other than going full STM on this?
replies(1): >>mathfa+t61
◧◩
4. mathfa+t61[view] [source] [discussion] 2021-06-13 02:48:06
>>spockz+wl
Yes a simple SCRM will do.
replies(1): >>abhish+pW1
5. abhish+jW1[view] [source] 2021-06-13 13:48:11
>>agf+(OP)
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.
◧◩◪
6. abhish+pW1[view] [source] [discussion] 2021-06-13 13:48:58
>>mathfa+t61
What is SCRM?
[go to top]