TicketMaster Design Deep Dive with Google SWE! | Systems Design Interview Question 12 

17:55 deal with concurrency, use locks on waiting linked lists 20:29 sharding by locality or events 21:16 write-back cache for waiting list , to update to the database which contains bookings.

Perfect man! It was detailed and realistic design. Thank you!

Thanks for the vid Jordan! Preciate the runthrough 👍

Thanks for the video! Quick question about the linked hash lists as a way to implement queues - how are these instantiated? I'm guessing there's software that creates this data structure every time the booking API is called but the corresponding lock is held? In that case we would return a response to the user and follow up with a SSE when there's an update (your turn to book, seats are unavailable)?

another great video! thanks! could you help me sort out some thoughts. i feel like most of ticketmaster like system do need to book specific seat, which means we do need to somehow lock in the per seat grabularity, and there probably will be a queue per seat. but these concept probably will be handled by relational database, when they handle concurrent transactions, and probably use hash linked list. but i feel like they probably wont be handled by application code. as for updating how many seats left, it is more like an eletronic commerce thing, where we care about amount, not location/adjacency. would love to discuss with you!

It's helpful if you actually draw the design while describing it. Otherwise, it's hard to understand/think about some of the concepts while also trying to visualize the design diagram in mind.

Hey, just thinking. Why don't we simply use a relational table (postgres or mysql) to manage Bookings? Like you can have a table for Active bookings and Waiting to book. Then when a user is no longer actively booking or waiting to book, we purge them off the tables via an offline process (batch parallel processing). 🤔. There could also be a separate notifications service that would notify customers based on a change in status (waiting -> active-> purchase etc.)

Hi Jordan, thanks for the great content series! Regarding this exercise, I have some doubt. Does your design allow parallel booking of different unrelated seats for the same show? If yes, could you maybe share highlight how it's done? In video things skip to active/waiting bookings but not relate seats too much. Regarding solution, it feels kinda complex, especially with Redis in-memory objects and 2PC to the DB. Due to not so high volume of reservations per show, a slow booking pace that spans over many hours, and easy sharding by show_id (so indeed scalable too), it does feel to make much sense to have an async working singleton service that contains all the logic regarding booking states manipulation. That is, once per every N seconds service loop happens which loads each of the shows, handles booking states updates, and saves it to DB. Single thread, no concurrency, super-testable, much more visible for engineers as opposed to Redis+DB. Plus, as it is single logic-executing actor, a much more complex seat-level logic may be implemented without risks of deadlocks etc.

I feel syncing with the theater's database to keep track of live seat availability was missed! Ticketmaster is not the only way to book tickets!

#suggestion I think Airline/Train reservation system would be the harder and more interesting version of this. We will need to think about range queries/updates for routes.

hey Jordan super quick question, was a bit confused with the in-memory data structure, are you suggesting to use Redis to keep that information and handle the locking on the node side? I was thinking of using Dynamo + locking and wonder why Redis?

Nice video, Jordan! Love the "Jordan's Sex Tape" gag. I had one question, wouldn't sharding based on event lead to a hot shard problem? Some events have a lot more people trying to book them and some have normal traffic.

what if the server crashes during 2PC ? how does it recover (Fault tolerance)?

Why not use sagar pattern istead of 2 phase commit?

getShowTimes should take movieId as a parameter, not just theaterId

is not ticketmaster for shows instead movies ? lol....