a lot of current system design videos including this one, lean towards an object-oriented design with box drawing, which might not meet the expectations for senior or higher-level discussions. I look forward to future opportunities for in-depth conversations on topics like resilience, scalability, availability, fault tolerance, data consistency, and their associated trade-offs.
Great. A small suggestion: Seat table contains isAvailable. However if there are multiple shows in same theatre, this variable doesn't have connectivity with associated event. Hence, we need either 1) eventId in same table, where for every event+seat you need to have a separate row or 2) Separate table that shows availability of seat for every event, hence containing eventId+seatId together.
If you don't get a chance to demonstrate all of your skills during the system design interview, that's okay; interviewers aren't always as knowledgeable as you. This could imply that the system's depth/horizon is highly dependent on the outcome of the conversation. I've been watching this great channel for a while, and I believe that having good communication skills is more important than system design itself in most system design interviews. Returning to the question. If I were conducting the interview, I would probably go into more detail about how to make the system more scalable, especially given the popularity of some of the events. I'd expect the interviewee to discuss rate limiting, write-back cache strategy if needed, optimistic lock for query and pessimistic lock for update, as well as some tradeoffs. If the interviewee can discuss how to resolve the issue by working with PMs, that is also very beneficial because tech may not be able to solve all of the issues. Sometimes we need to change our minds.
You don't have to buy the exact seat. You can buy a seat in one group that is close enough. Also, last 5-15% per group, you don't have to be able to buy online. With this approach, you would have less than 95% of his design's choke points. It would be much cheaper and easier to create. For the deadlock, you don't have to update the row, you can just add additional row that states that some row is taken. Much cheaper than update, and no deadlock. Getting n items (where n is max number of seats) is cheap.
Make sure you're interview-ready with Exponent's system design interview prep course: bit.ly/3ZNtB37
a lot of current system design videos including this one, lean towards an object-oriented design with box drawing, which might not meet the expectations for senior or higher-level discussions.
I look forward to future opportunities for in-depth conversations on topics like resilience, scalability, availability, fault tolerance, data consistency, and their associated trade-offs.
Great. A small suggestion: Seat table contains isAvailable. However if there are multiple shows in same theatre, this variable doesn't have connectivity with associated event. Hence, we need either 1) eventId in same table, where for every event+seat you need to have a separate row or 2) Separate table that shows availability of seat for every event, hence containing eventId+seatId together.
In my opinion, system design is essential for every engineer, so I think it's a great learning resource.
I am grateful for the content!
Mentioning that you plan to store user credit card numbers in the database is likely to lead to a failed interview.
These videos should go quickly into edge cases and how we solve otherwise.. its no brainer stuff!
If you don't get a chance to demonstrate all of your skills during the system design interview, that's okay; interviewers aren't always as knowledgeable as you. This could imply that the system's depth/horizon is highly dependent on the outcome of the conversation.
I've been watching this great channel for a while, and I believe that having good communication skills is more important than system design itself in most system design interviews.
Returning to the question. If I were conducting the interview, I would probably go into more detail about how to make the system more scalable, especially given the popularity of some of the events. I'd expect the interviewee to discuss rate limiting, write-back cache strategy if needed, optimistic lock for query and pessimistic lock for update, as well as some tradeoffs. If the interviewee can discuss how to resolve the issue by working with PMs, that is also very beneficial because tech may not be able to solve all of the issues. Sometimes we need to change our minds.
We need a domain driven design approach to these system design interview videos please
yeah, I am not clearing my interview tomorrow. But thanks for the video
Thank you! Yours videos are helping me a lot.
He did an incredible job! Thanks for this, very helpful!
what is the tool name?
You don't have to buy the exact seat. You can buy a seat in one group that is close enough. Also, last 5-15% per group, you don't have to be able to buy online. With this approach, you would have less than 95% of his design's choke points. It would be much cheaper and easier to create.
For the deadlock, you don't have to update the row, you can just add additional row that states that some row is taken. Much cheaper than update, and no deadlock. Getting n items (where n is max number of seats) is cheap.
you could use ttl to manage reservations
What is the app used to take notes on?
Hey komilp8310! The whiteboard used here is called "Whimsical"
why spent so much time on table schema design?
Why designing under DB this make don't scalable code? why non't ddd?
Using verbs for POST endpoints in api design... hmm...
ACID database?