Don't leave your system design interview to chance. Sign up for Exponent's system design interview course today: bit.ly/3TAr4YQ
@handsanitizer2457 Жыл бұрын
What program are you using to make the plan
@okeyD902322 жыл бұрын
She is really simulating the real job interview, checking the phone in middle and acting like she is listening and responding with 'yes, yea' 😂 😀
@AbhishekBalani936 ай бұрын
And not questioning on anything like the things I mentioned above.
@cco3 Жыл бұрын
I interviewed at Amazon some time ago, and this was the first design interview question I had ever gotten, so I had no idea what to do with it. Moreover, the interviewer didn't say "a reservation and payment system for a parking garage", he just say "a parking garage". So I started drawing the levels of the parking garage and making decisions like using angled parking spots because I like angled parking spots.
@tryexponent Жыл бұрын
👀
@punstress7 ай бұрын
Yep! I thought that too, because I knew an engineer who designed lots and garages. There is more to it than you might think.
@evalyly93134 ай бұрын
😂😂I really laughed out with tears at this reply
@abhinaw12323 ай бұрын
🤣
@kartikaygoel30423 ай бұрын
😂😂😂😂
@klahanie3 жыл бұрын
This interview seems reasonable
@tuanvu51613 жыл бұрын
Ikr they used the word 'reasonable' a lot :)) that maybe the trick to ace your system design interview
@17teacmrocks3 жыл бұрын
probably. presumably. and obviously
@prabhjeevnijjar45913 жыл бұрын
@@17teacmrocks and optionally
@igorwiwi43303 жыл бұрын
I think that's fine
@ethanj15333 жыл бұрын
Obviously
@praveensg2 жыл бұрын
Neamah needs to talk more (or even interrupt) and ask challenging questions. He seemed like he came in with the solution in mind and went through it godspeed.
@NainoaFaulkner-Jackson2 ай бұрын
Yeah this. Obviously this is a mock interview, but it's really clearly none of this is being improvised, and that he already knew the answer.
@YorozuyaNeesan20102 жыл бұрын
This was so helpful. I basically have my first system design experience in an interview tomorrow for an internship. I feel like that's the point where I will fail, but this is at least helping me see what kind of thought process I need to get in to. So regardless of how I do, THANK YOU for this. EDIT: I got an offer for the job and I am certain watching and learning from this video the night before really, really helped, so THANK YOU, AGAIN!!!
@gabrielk22952 жыл бұрын
So, how it went? (I have an appointment tomorrow ..)
@gabrielk22952 жыл бұрын
@@YorozuyaNeesan2010 congratulations!!
@itisyerdad2 жыл бұрын
Congrats on the offer!!!
@gabrielk22952 жыл бұрын
@@YorozuyaNeesan2010 You want to ear a funny story? The day after I saw that same video, I had an interview , just like you. And at the end, I had a job offer too :D
@Pratham99Esh2 жыл бұрын
I have my (final) system design round tomorrow guys. 🤞 I hope to join the club.
@BenjaminChevoor3 жыл бұрын
Good system design interview problem and solution! Thanks for sharing! Keep in mind some interviewers look for you to ask clarifying questions at the beginning more than Tim did here. Questions on: 1. who are the users? 2. how are they going to use it? 3. what use cases are there? 4. what are the inputs and outputs? 5. how much data do we expect to handle? 6. how many requests per second do we expect? Tim made a lot of assumptions while building his solution. This could have gone down the wrong path and wasted time.
@kristopherleslie83433 жыл бұрын
And coincidentally he didn’t :)
@christianmosley55733 жыл бұрын
@@Appocalypse very reasonable
@collinyan74673 жыл бұрын
he made reasonable assumptions, and verbally justified them and the interviewer agreed.
@stillmattwest3 жыл бұрын
This was awesome. Great resource for those wanting to improve their interview style.
@CerebroneAI2 жыл бұрын
Yeah , asking questions is important rather than jumping in to solution. Looks like dude was aware of the solution and did a prep work before this recording. Asking questions will help the interviewer to assess your communication and how deep you can go with your understanding. Presuming bunch of aspects to solve the problem will not work in real world. It’s not a one man show but a team work and Synergy. I would hire someone who would ask bunch of questions before jumping into solution
@Keilnoth3 жыл бұрын
You know they interview for big tech companies when budget is never mentioned in the conversation, especially as they start adding sharding and replicas right away. 😅 I'd definitely ask questions like how many users do you expect? How many garages? How many locations? Is it local, national or international? And adding a load balancer in front of the backend seems quite reasonable too so you avoid scaling it vertically.
@f137752 жыл бұрын
I think one of best comment out here :), you definitively should have scaling in mind but putting load balancers and replicas for garage app? Really :)? lol thos engineers will build you skyscraper when you need doghouse and will charge you as for spaceship
@yourcondition30792 жыл бұрын
@@f13775 LMAO - thanks for the humorous response , made a net positive today in my life.
@blasttrash2 жыл бұрын
just googled and the biggest parking lot in the world is the West Edmonton Mall in Canada and it can accommodate about 20,000 vehicles. Which seems to be a very small number and any metadata that gets generated by this can easily be stored in a normal sql database without worrying about scaling afaik. correct me if I am wrong though.
@satyamsangal66592 жыл бұрын
@@blasttrash my question was why do we need a DB at all? We need less than 5gb in-memory .
@blasttrash2 жыл бұрын
@@satyamsangal6659 coz RAM is volatile and if ur system crashes, ur data is lost
@DoJoStan3 жыл бұрын
Wow this was excellent in how it went through it systematically 1. General Requirements 2. Endpoints (External/Internal) 3. Data entities 4. High level architecture but still kept it conversational. This was super helpful!
@nikilragav3 жыл бұрын
I definitely would have gone 1, 3, 4, 2 but I love this format and love how they were able to talk through the design tradeoffs in a conversational way
@ddoice3 жыл бұрын
@@nikilragav yep, me too, a good understanding of the data entities and their relationship is the key to avoid pains later
@michaelibrahim83603 жыл бұрын
@@haydencordeiro Public APIs are ones that the browser(user) will call directly. An example of that is the reservation API which the user will have direct access to, and the response will be directed back to the user to get their reservation. Internal APIs on the other side are somewhat hidden from the user, In other words, their immediate response does not get directed to the user right away. Like the spot allocation API; the result of this API is directed to the reservation API which in turn will respond back to the user with the reservation :)
@thunderzz22333 жыл бұрын
@@michaelibrahim8360 Create account should be public then? How'd the app register an account without a public api?
@ahmedal-saghir34212 жыл бұрын
@@thunderzz2233 I'd like to know that as well
@ishaanme913 жыл бұрын
I really like that he talked about finer details like data type tradeoffs (enums for car type, decimals for payment calculation), security considerations (storing hashed passwords), scalability (read replicas), and write consistency requirements. But, what made this stand apart was the specific DB details that he was able to share. That showed technical depth and is bound to ace interviews. Thanks for the good work!
@abhishekbajaj1093 жыл бұрын
No fresher will ever be able to produce this with that much of depth
@Thepankaz13 жыл бұрын
@@abhishekbajaj109 but dont they study it in college.
@varshard03 жыл бұрын
@@Thepankaz1 I don't think most of colleges teach about scalability especially the way to improve each db's scale technique. Teaching which data store suit which use cases would be ideal already. CAP theorem should be a must taught lesson, but it's not.
@TheCyber_3 жыл бұрын
money better to store in cents, like BigInt
@zzjxchsnonezjxx3 жыл бұрын
100℅ right. All these small in depth details make this guy stand out among the others.
@exclusive6053 жыл бұрын
I had an unreasonable amount of ads while watching this very reasonable interview
@ramsriperumbdr6023 жыл бұрын
use ad blocker or brave
@terrabyte-techy3 жыл бұрын
With adblocker, KZfaq cannot unreasonably scale out the ads, you filter them out like a network ACL trying to filter a malicious IP.
@sajackson3 жыл бұрын
@@ramsriperumbdr602 It's reasonable to expect some are watching on a phone app with no adblocker
@kattasudhir3 жыл бұрын
@@sajackson use PI-hole for your network
@kennethcarvalho36843 жыл бұрын
lol
@radhouze25543 жыл бұрын
19:57 "This looks... reasonable" lol he got her to start saying it too
@qualdatatechnologysolution40766 ай бұрын
It's called limbic synchrony. It is a survivor instinct. It is what happens when you are around a more knowledgeable, more powerful, more something person. She mirrored his words because she knew nothing or felt she knew nothing compared to him...and instinctually did it to survivor her own interview. It is a powerful concept to study.
@johnpaul43016 ай бұрын
@@qualdatatechnologysolution4076 Exactly lol. It's so obvious she doesn't actually know much about swe. She literally just agreed to everything he said and suggested
@SeyferX3 ай бұрын
I started laughing at this point and could no longer take it serious
@oluyemiolususi6972 жыл бұрын
This is a reasonable design, by a reasonable Engineer on a reasonable channel. You have got yourself a new reasonable subscriber.
@nimishverma78922 жыл бұрын
No cross questioning, so many assumptions while designing. Very reasonable interview!
@MSNandoKun3 жыл бұрын
What are we going to call the app? “Reasonably”🤣 Good job though
@nalakamanathunga64783 жыл бұрын
haha
@jasper50163 жыл бұрын
lol
@PrakashBesra3 жыл бұрын
Good app name
@luv-nnd3 жыл бұрын
I am sure you are working for FANG.
@teaberry733 жыл бұрын
Presumably, yes 😂
@pimpleberry Жыл бұрын
Honestly a pretty good solution considering Tim said he'd only be an engineer for a couple of years. Here are some of my suggestions/critiques on what could be improved imo: - Start with the high level system design; this will help inform the lower level design choices (like the API endpoints) - There was no endpoint for customers to view available spots; probably the FIRST thing a customer would look to do on any UI - A status enum on the spot table only really works if you can only make real-time reservations, and not in advance. And for a web/mobile UI, an in-advance reservation system is the only thing that makes sense (hence the consistency requirement) - Read replicas for consistency = bad, I'd opt for NoSQL for horizontal scaling. The write requirements for this design are minimal - Create account and login are not internal endpoints - I'd consider an as-serverless-as-possible design to keep costs low (modern serverless solutions are easy to implement, scale and extend) - AWS API gateway as the entry point backed by lambdas to retrieve available parking spot info. An AWS Step function workflow(s) would orchestrate everything to do with making the reservation (take payment, create reservation, issue receipt, email receipt etc), but a monolith for this scale of problem seems fine too
@tryexponent Жыл бұрын
Hey pimpleberry, thanks for sharing your thoughts with the rest of the community!
@nile79994 ай бұрын
opting for a horizontal scalable db for a parking garage reservation system is crazy
@pimpleberry4 ай бұрын
@@nile7999 I'd love to hear why you think that's the case. Horizontal scaling has lots of benefits: more scalable, cost effective, higher availability etc - and it's not something you are tied in to necessarilly, but is an option if you need it later down the line. And solutions like DynamoDB abstract away a lot of the complexity to do with partitioning data
@appsky79823 жыл бұрын
This is a very good one. I've watched other interviews where they proposed to build their own protocol and use CQRS for everything. This guy kept it simple and didn't reinvent the wheel.
@89DerChristian2 жыл бұрын
Probably wanted to show off their skills and knowledge, while the business just wants it quick and easy
@Leto2ndAtreides3 жыл бұрын
Business requirements needed to be fleshed out more in the beginning. Fleshing out the flow for the user would also make this easier to model.
@Mercury12343 жыл бұрын
Absolutely. I would have went use-cases/reqs then model and finally the system (and apis)
@yourcondition30792 жыл бұрын
question here, would be use-cases be given by a supposed product manager? If so, would this all be predetermined by the PM?
@amitankur113 жыл бұрын
Personally, I think this could have better if they can take care of some sort of flow charts before diving into Public Endpoints or API Design.
@vib77772 жыл бұрын
I don't think a flow chart can be created in the starting because in system design flow goes from high level to deeper level.
@asmitachatterjee89792 жыл бұрын
Watching this as a product manager to learn more about how SDEs approach a solution. Very educational! Thank you!
@mangofreeze12292 жыл бұрын
A big question mark here that is fundamental to a the problem: how do you decide whether a timeslot for a particular garage is available? Different people book different lengths, the remaining available slots is dynamic over time. It's not a movie or air ticket booking system. The interviewer didn't ask this fundamental question at all.
@AllGreenThumbs2 жыл бұрын
Maybe too high level for the reservation algorithm details. But forefront in my mind is overstays, which will break a reservation. You can't just delete a car when their time is up.
@andrewferguson69012 жыл бұрын
@@AllGreenThumbs that's a great point, youd actually need to take note of when cars both enter and leave
@firezdog11 ай бұрын
Yeah I agree -- I'm 22. minutes in and I'm waiting for him to talk about how he's going to deal with the race condition where two people try to book the same slot at the same time -- or someone tries to book a slot that they see as available and in the meantime it's already booked -- or how you deal with "locking in" slots temporarily while payment is processed and then potentially canceling the lock if the payment falls through. Or just general issues with transactions that have to be canceled in mid-flight and how you clean up after them. Well I guess he did sort of address it with the read lock, but this is a pretty important topic to discuss IMO
@punstress7 ай бұрын
While of course this is fictional and I don't know of any parking garages that reserve specific spaces, I have booked zipcars where the person did not return the car in time for my reservation. The computer knows in real time that it hasn't been returned and notifies me, and the late person gets a nice penalty fee. In the case of a parking space, if they can detect that the car is still there, they can notify the next reserver and simply ask if they would like to wait or take space XYZ that is available. There is also the problem that someone might park in the wrong spot or park like an idiot so that you can't squeeze in or out of the space, but there are probably endless what-ifs to every scenario. But putting a bit of a buffer of 5-10 minutes after the previous end time might be enough to solve most conflicts. If I get there a few mins early and the space is open, I can pull in. (Actually now I'm realizing there is a problem of letting someone in too early for their reservation. Cars are going to stack up waiting for their spot to open up. Reserving a specific spot is a terrible idea!)
@beiller842 жыл бұрын
Really liked the video! 2 things I notice: 1) The payment is directly connected to the backend in the diagram. For many payment systems I have worked on, the front end also connects directly to the payment provider using something like "generate payment token" so that credit card details are not sent directly to the backend and it doesn't have to handle sensitive information. 2) Database consistency is glossed over a bit, because there is a write server, and 2 read replicas. He mentions using a read lock. But can a read lock exist in the read replica before it knows a record exists in the main database? I think personally it may be overkill to have read replicas here, because the volume of data read/written is not high enough to warrant the replication. Maybe sharding will work better if the storage layer is a bottleneck, where we split the databases into 1 database server per parking garage.
@BlackIceSpa2 жыл бұрын
Apart from not being needed (probably a Cache with evict on write would be enough), I'm not sure how good read replicas are if you want high consistency. I'm not very familiar with Postgre, but read replicas are usually asynchronous.... Also transactions are not really complex here (as long as doing a reservation is atomic), a DynamoDB with optimistic locking could be enough (to retry if you missed). Although in reality I would just drop a SQL database and let it handle everything, which its not much.
@micky83312 жыл бұрын
One db per parking garage? How would you support the very common feature of looking around a map and loading garages and their prices for a downtown area?
@christinakayla10 ай бұрын
@@micky8331 Garage data is small, we should be able to put data from all garages in a city in one shard.
@kenwang85955 ай бұрын
Sharding is even more an overkill. For this simple system, performance is not a consideration but fault tolerance. So, a standby DB may be needed. The backend server also better be a cluster fronted with a load balancer.
@Saurabhk153 жыл бұрын
Great discussion - I always find depending upon what you are thinking at the moment - a lot of things change. Like, I did not think of the Reservation-based Parking System, I pictured traditional garages - where you can drive through without pre-booking (why - mentioned in the end) 1. it shows number of available slots 2. you enter with any one of the multiple gates - where you receive the parking ticket (containing the spot_id with timestamp) 3. when you exit the price is calculated using the flat_rate* (end_time - start_time) NFRs I would consider - I own all garages in a country (so i have some scale) - My backend server can hold all input-output data and keep information about a vehicle for about 10 years (persistency) - payment calculation needs to be really fast - maybe an on premise lazily distributed system might also work if performance is the key! The reason i didn't think of pay-reserve mode works is about efficiency - I see lots of parking spots vacant in office buildings. But I was thinking towards a shopping mall - maybe. So, it might be a good point to clarify with the interviewer. Would love to see a LLD for this :)
@punstress7 ай бұрын
There are a lot of different types of parking lots! I thought well you need to separate long-term and short-term parking because I thought about a NYC garage or airport garage where you have some vehicles parked for a week or longer and they should be in a less convenient place that might involve a day's notice to get your car out. I also wondered why there was no check-in because I presumed the system would also be used at the garage (maybe I missed it).
@croci816 ай бұрын
That kind of interview is quite nice. As an old system designer, I instantly started to think about the database (and normalization rules). It works as a backbone for my thinking process and it also helps me product planning and communicate with my clients by asking questions even though I do not have a database on that point.
@BangMaster963 жыл бұрын
I'm gonna leave a like to this video, it seems pretty reasonable.
@properwaffles2 жыл бұрын
Absolutely love listening to someone map something out like this on the fly, very interesting and informative.
@heyitsaamirj Жыл бұрын
I'd rather shard on garage id as opposed to zipcode. It's reasonable to assume that garages themselves can be logically separate entities, and won't have conflicts. This allows you to read-lock a garage specifically as opposed to an entire region.
@punstress7 ай бұрын
I was thinking there might be a cluster, for example you might want to park in structure A on a campus but if it's full, let me know that structure B has space.
@kunalpareek83212 жыл бұрын
A key point that the interviewee missed was that Parking Spots are not in a binary state of being booked and unbooked. To decide the booking and unbooking state of a spot one needs to look at the reservation table and this will be a dynamic information based on time slots which the UI should be able to query by. This was a big missed point according to me. Another thing is with the read write replica decision. If there is going to location based sharding then any single database shard should be able to handle both read and write traffic considering that each shard will then have even lower traffic (not that many parking spots in a location possible) This will make the system simpler and more performant and eliminate the need for region based locking completely.
@jl789nz2 жыл бұрын
When he was talking about the status being reserved, I think he meant that the parking spot is reserved for maybe someone who has a long term lease on a parking spot, or is reserved for service vehicles. Having a status field could help with this, but again there are others ways to solve these issues too.
@theoneed20512 жыл бұрын
The problem and scenario as given is relying mostly on the interviewee's assumptions and prior knowledge of how parking garages work, I don't think the test would be fair if it's gauging the interviewee's accurate knowledge of in/outs of parking garages, and what users/owners expect. Requirements are provided to him, and it's always best when the developer is familiar with the problem he's going to be solving, but he shouldn't be expected to know the in/outs of parking garages and what users/owners want.
@idotsuk2 жыл бұрын
Exactly, and this will be extremely costly using this design. If it's really so read heavy, which it is, it should do those aggregations when making a new reservation. Also, using specific parking spots and handing them out randomly could mean space is not optimized.
@HydeMyJekyll2 жыл бұрын
I don't understand how this could be a valid example of an Amazon interview question. This is stuff I learned in my first ever class on database stuff, like... the very first thing I ever learned about it. I could answer this question pretty easily, but I doubt Amazon would hire me as a System Designer.
@lbb2rfarangkiinok2 жыл бұрын
Yep.
@gopalakrishna96512 жыл бұрын
they wont. lot of loose ends
@sumonmal0093 жыл бұрын
complete requirement and API 11:04 DB schema 19:30 HLD 23:20
@kumarashutosh2292 жыл бұрын
One thing one might want to get into is: 1. How are we initially loading the datasets(the source of parking slots)? 2. How to deal with increase/decrease in number of slots? (externalized configurations) 3. Class level diagrams of race-conditions, like how our api will behave with locking of slots
@ChristianBrugger2 жыл бұрын
Also spots might temporarily became unavailable due to maintainance or permanently changed. Then what do you do with the existing bookings? You need a whole email managing system. Shift them, what if everything is full. Etc.
@MrOsirisDL2 жыл бұрын
I felt the system scale part can be designed/cleared in the second part right after the requirement. Because the garage system can also be designed to manage multiple garages in different locations. In this case, we can use a distribution system to handle the backend system, the endpoint and service design cant be totally different.
@JoseHernandez-ye9lm2 жыл бұрын
Normally load balancer are used before the backend server in case you want to scale out those backend servers. I think only shard function before the read dB is enough
@AleksandarMafilovski2 жыл бұрын
Load balancers should be used only for user facing servers, because that’s traffic you cannot control. For internal traffic (one api to another, backend api to database) you should have library that will read from config (consul comes to mind) and balance the traffic. Why? Because load balancer adds hardware complexity that you need to maintain. You always need to have failover strategy (usually master slave strategy). You will never see load balancer used like this in large scale company
@harmanbirrai56762 жыл бұрын
@@AleksandarMafilovski My company have 8 oracle nodes , and they are load balanced 3-3-1-1,and its not even a distributed system .. still oracle nodes are load balanced .. to equally balance the traffic routing of incoming read / write requests..
@AleksandarMafilovski2 жыл бұрын
@@harmanbirrai5676 why not implement that logic in code and use Consul or similar for service discovery? I think you are using Loadbalancers as substitution for service discovery, which I don’t think is a very good idea
@vasum58663 жыл бұрын
As a garage admin, i would also like to be able to add new garages/spaces and/or remove them. There should also be ability to set/modify prices to various spots.
@bitzartdev3 жыл бұрын
Yeah that is what I spotted when he started with his endpoint design. He is missing proper structure. For example, the reserve endpoint should be /garages/{garageId}/reserve. This leaves us with a whole /garages endpoint where you can do everything you want with garages. And this would create a good API structure. And for /payment, it should be more like /reservations/{resrvationId}/pay, which leaves us with a whole /reservations endpoint. Following this path would leave us with a proper and easy-to-use-and-understand API instead of random arbitrary endpoints
@realjasonlima3 жыл бұрын
As a garage user I would like to rent my garage spot to a second user so that I can earn money with my currently owned garage spot asset.
@varshard03 жыл бұрын
@@bitzartdev He mentioned GraphQL. So, I don't think he intended for it to be REST APIs, but using it as sort of a placeholder instead.
@whatTheFcuk93 жыл бұрын
Incredible. one of the best system design video's I have seen. Tiktok video from exponent is really good too. Please make more of these.
@tryexponent3 жыл бұрын
Thank you so much 😀
@DesignStrong3 жыл бұрын
Hey, I agree with your feedback. We are also trying the same
@jhanvidattani81967 ай бұрын
Thanks, Neamah and Tim for the awesome explanation. One thing I wanted to add is: The spot table should have one more field named available_time (a timestamp), this field will tell what time onwards the parking spot will be available. Initially, the value of available_time would be the start of the day let’s say 9:00 AM, and as and when people start parking available_time = end_time. Else we would never be able to calculate at a given xyz time whether a spot is available or not.
@punstress7 ай бұрын
Good point! But maybe available_time = end_time + 5 minutes !
@jhanvidattani81967 ай бұрын
Yeah that makes sense to add 5 min so if let’s say system is not updated at exact time then after 5 min it would be definitely updated
@almasabdrazak50892 жыл бұрын
I don't really like the solution 1. Why do we keep garage_id in reservation if splot already contains the garage it belongs to 2. In terms of foreign payment API, how backend will handle transaction between database and internal API 3. The biggest thing in terms of booking system is a reservation, how to handle the case with miltiple users booking same slot in different times between interleaving each other, I think it was the main point of design. candidate basically said, Postgres, Backend, Frontend which can be applied to any system
@Omeomeom2 жыл бұрын
I love it, these people are losing themselves in the moment, really coming into themselves and their voices, and absolutely killing it in the communication department. Rock on!
@deviatedproxy88662 жыл бұрын
Need to factor few additional dimensions: - Number of total parking spots - Parking maintance windows - Placeholders for pricing changes ( Offers / monthly passes / timing changes ) - Scalabile / Multitenancy aspects
@punstress7 ай бұрын
I believe he did mention designating a spot as unavailable for situations like maintenance but the maintenance itself would probably be tracked on a different system. He also asked about various price tiers but she said to assume all flat rate. If they tell you to keep it simple, keep it simple!
@adamjohnstone92253 жыл бұрын
For the database schema, a simple status enum for the spots would not be sufficient to determine when a spot is booked and for how long. Determining how to represent the spot's availability efficiently is an interesting aspect of this problem which was completely disregarded by both interviewer and interviewee. Perhaps both parties assumed that spots could only be reserved from now until some point in the future, but that should have been explicitly called out. Building such a restriction into the schema would be poor design regardless.
@saketk213 жыл бұрын
Great point! If I am not wrong you mean that the design should allow booking of a spot from some point in the future to some further point in the future. I'd approach it as follows - 1. Since the spot being available or not is a transient property of the system, my first thought was that we can get rid of the status field altogether from the spot table. The availability of the spot should be calculated in the business logic. 2. For that matter, we can add start_time as the sort key of our reservation table. 3. Queries in the form of "Get available slots from start_time to end_time" will thus be supported in our query language. This opens up new avenues of questions - what if a reservation has reached it's end time, but the spot has not yet been vacated? Should we incorporate some penalty/late fees for this kind of usage? This is a feature that this would be required - and hence at exit from the spot, we should have a vacate_spot(reservation_id) endpoint, which will calculate the balance and mark the status as vacated. This would probably make me bring back the status field in the spot table, which would depict the status of the parking spot at this instant, and whenever a reserved spot exceeds the end time of the reservation, the system would mark it as LATE or something of the sort. Now until the status changes from LATE to AVAILABLE, all further queries for getAvailableSpots should not return such LATE spots. Please let me know what you think of this. Also your comments/remarks are welcome!
@varshard03 жыл бұрын
@@saketk21 Your reply is informative, even went into edge cases like over parking. However, since you are going to reserve a spot in advance, which check from reservation table, the current status of each spot will matter less. ie: if I want to reserve for tomorrow, then the fact that a spot isn't available today doesn't matter. A proper garage would vacate the car that overstayed its reservation. If the spot is unavailable because of a maintenance schedule, then that can be done as a reservation also.
@dimitristripakis73642 жыл бұрын
You are right, and also it is not possible to know how long you will park for, say for dinner, shopping, etc. So payment must also occur when leaving, not only during reservation. It gets quite complicated if you add real life details.
@harrywang93752 жыл бұрын
Not really all that difficult. Reservations are mostly time based and therefore if you are booking a spot in advance, it seems fairly obvious that you would book a start and an end time. At worst, you might discuss with your interviewer but I'd say it's quite safe to say a start time and end time in the DB is sufficient
@joshhoover12022 жыл бұрын
@@dimitristripakis7364 Yeah, another detail is what to do if someone overstays their reservation.
@considerphi3 жыл бұрын
Hey @exponent, these are great! I'd suggest some actual feedback would be good too. Not necessarily to the "interviewee" but an after the fact breakdown of the choices made. Like a debrief where you go over what were the weaknesses/strengths of the interview solution. For e.g. x chose to put a read replica db, for this kind of solution we usually prefer to see z because of this. Or, the read replica db is a good solution for these reasons. We're looking for a good understanding of y. That way we don't just assume that everything said is the only/right way to go about this.
@pereerecodes2 жыл бұрын
I really enjoyed this. I do and build lots of software and the design part is always very satisfying to me as you can see the whole system's wireframe before you before you even start building.
@JamesJSwiftJay3 жыл бұрын
I have a system design interview coming up and this has helped me get a better understanding on the thought process a lot. Thanks!
@abdullahyahya24719 ай бұрын
I guess watching it second time after a year, I realize that if an interviewer would have actually asked more technical questions to mimic the real world that would be more helpful, as I had some questions about the tradeoffs etc. And I feel there was no one to challenge his approach. None the less, Video is helpful in many ways.
@tryexponent9 ай бұрын
Hey abdullahyahya2471, thanks for the feedback!
@hitchbear3 жыл бұрын
28:09 is ultimate reaction
@abhijeetbedagkar31432 жыл бұрын
Any idea which tool he has used during the interview to explain APIs, DB schema and high level arch ?
@tugceakn9742 Жыл бұрын
Whimsical
@aeoluseros2 жыл бұрын
I've never entered a parking garage that needs me to reserve a particular parking spot. So it took me some time to understand Tim's cocern about "allocating to the same spots at the same time".
@maxfan60352 жыл бұрын
I feel a common use case is we “reserve” a slot by parking our car there first. So, “reserve” is not a concern at all.
@rahm97172 жыл бұрын
With his high level architecture I think the usage of read replicas would actually go against his ideal of having high consistency since it would take time to propogate writes across the DB shards.
@yilinma83672 жыл бұрын
right, and he didn't mention it should be done as sync replication.
@syedishrathullah3 жыл бұрын
Superb interviewee....he looks so poised.... and the way he took the feedback is next level...
@pb7379-j2k3 жыл бұрын
Well he was talking to his friend with nothing to lose...
@amanpathania2 жыл бұрын
@Exponent team: Quick question - how did Tim categorized endpoints into External/Internal? The reason I am asking is: /createAccount - should that not be a public endpoint?
@derpnerpwerp2 жыл бұрын
Exactly! Also /login.
@cordrehn81402 жыл бұрын
The entire idea of an account system here is garbage. Who would ever register an account, username, password, etc. just to park their car for 2 hours? The paid parking lots you see in cities have a simple QR code and a lot number. You download the app/mobile web from the QR code, punch in your lot number and license plate number and how long you want to park for. No accounts, no usernames, no passwords. Supporting parking spot reservations makes no sense unless they plan to tow cars that overstay their parking times, I would push back on this requirement absolutely.
@ivanvlopes2 жыл бұрын
It was nice, but the amount of assumptions really bothered me. Important questions for the design were not addressed, such as: is payment processed at the moment of reservation? How cancellation works and what's the cancellation policy? Is money being returned in full upon cancelation? Cancellation is a public endpoint, how do we ensure only the owner of the reservation is allowed to cancel it? Can users choose parking spots, or you randomly get assigned one? If you can choose parking spots and have a compact vehicle, do you see spots for larger vehicles reported as available right away? If you do own a compact car, and reserve a larger vehicle spot, are you only paying for the cost of a compact spot? Tim also showed himself overly confident on his solution, making it feel a lot less like a collaborative effort, which can be either a positive or negative thing depending on where you're interviewing. He was constantly stating that what he had just done was reasonable (hah!) and enough. I'm not an experienced interviewer, but if I were to be his co-worker, he would not look like a good team player. This is just my personal opinion, and maybe I am the one wrong in interviews for not doing like Tim, so I'm open to opinions. In general, he seemed eager to jump into the implementation details, went into too technical things, while not asking the more broad questions that would have a heavy impact on the system design.
@DavidXNewton5 ай бұрын
Thanks so much for putting a mock interview online - I'm nervous enough doing system design with an audience of one, never mind a million people reviewing the video afterwards :)
@caleb7475 Жыл бұрын
Interviewee: So this is how it's going to work. Interviewer: Yea, I think this is good. Repeat
@malavsoni68142 жыл бұрын
This is a good system design question and I really like the way it was solved. 3 things I notice that should be taken care of. - We should include payment_id in the reservations table. - add a number of spots under the garage table to detect whether any spot is available or not. - How can we manage the status of the spot from the Spot table as it's going to depend on the start and end time of reservations. (e.g Spot is available today but booked for tomorrow so what will be the status of it?) - Maybe we can have an array of future reservations to that spot. WDYT?
@OnlyForF12 жыл бұрын
This video was amazing and was a big part in me acing my system design interview with Atlassian!
@magicharley52642 жыл бұрын
The interviewee's flow and pace are good. I may not perform better if it were me:). I failed system designs several times:) However, this interview will not pass in a real scenario . Here are some issues with this session. 1. The interviewee emphasized "high consistency", but he never mentioned how the consistency was solved. This is actually a tough problem. There are several approaches a) read-write transaction with index-range lock. Most of people understand row lock, and table lock. Index-range lock is the solution here. b) append only with offline adjustment. c) synchronize reservation for each garage. 2. DB schema: Spot with status, and allocate_slot don't work for reservation if you think this a little bit deep. At interview time, one may not discover this doesn't work. However, interviewer asked the questions so many times, and knew exact all the pitfalls one could fall into. Once you give slot with status, or allocate_slot, you fail the interview. Of course, interviewer will discuss these tables and give one a chance to correct the design. 3. How is "/payment" implemented? Do we keep track the payment at our side? This use case is not elaborated. This is one of two major use cases 4. We have /reserve, and /pay? How do we coordinate to make sure both succeed or fail? The system is not stuck in half success state? We need a flow to accomplish the reservation. We may need offline compensation. 5. The interviewee mentioned we had more "read", then we need "read" replica? What are the "more read"? Can a singled sharded DB handle the read/write Tx?
@stillmattwest2 жыл бұрын
IDK, if you give a random system design prompt like "design a parking garage" and you get back this quality of answer and then don't hire the guy, I'd question your decision making. I don't hire for Google or anything, so take my opinion with a grain of salt, but I'd consider this a great interview even for a senior dev.
@MyGroo Жыл бұрын
The first thing he typed (/reserve endpoint) seemed a bit lacking to me though: 1) no vehicle type specified, 2) input parameter should probably actually be a spot_id returned by /freespots, because that's how you would likely start the reservation workflow. 3) what happens when there are no free spots?
@jvm-tv3 жыл бұрын
A parking lot system does not really need DB sharding. A parking lot is not that read-heavy to need read replicas.
@shashikantsharma35513 жыл бұрын
Exactly....Think 1000 times before you shard your DB. There's lots of stuff can be done before implementing DB sharding.
@varshard03 жыл бұрын
@@shashikantsharma3551 Agreed. I like to point out that what the interviewee did wasn't sharding, though. It's read-write replica. This is better than sharding because transaction still hold and data on 3 databases are 100% replicated from the write db. It's only improve read, but not write, though.
@madhurimalahiri35793 жыл бұрын
Replicas would also ensure high availability and fault tolerance for the data store even if read latency is not really a concern. Yes, agreed before sharing the data there needs to be additional considerations however replication is pretty standard. Infact, a db snapshot/backup may be good enough for low scale systems depending on the use case.
@TanInVan2 жыл бұрын
The issue with read replicas will always be eventual consistency over immediate consistency. Especially if the consideration is lets say a front end showing the slots available, showing the wrong slot, and trying to write over it will be an issue. Yes you could use just the write replica as a way of showing the data ofc but then that depends on the design, are you using read replicas only for the PoS terminal or its for web ui use as well.
@BuzzTheLobuz Жыл бұрын
Once there was a guy named Joe, Who thought everything was quite slow. He'd say "That's just reasonable" No matter the task, it was always bearable. But then there was a girl named Sue, Who thought everything was quite cool. She'd say "That's just fine" No matter the challenge, she'd never decline. Together they'd go on their way, Joe thinking it's okay and Sue saying it's okay. They'd laugh and they'd joke, And they'd never need a poke. Because they knew that in their minds, Everything was just fine, not a bind. So if you ever see them around, Don't be surprised if they're just hanging around.
@praneethkumar7884 Жыл бұрын
How did you come up with this dude? How the hell! How much time did it take for you?
@rakshamohan2 жыл бұрын
The interviewee assumed everything is 'reasonable' while the interviewer kept nodding to everything he said! Real interviews are not this smooth. :-) But, watching the approach he took was good learning.
@grabteawithme2560 Жыл бұрын
i loved this interview it was top notch. I could feel both interviewer and interviewee were extremely experienced and confident.
@sabriath2 жыл бұрын
I would have added the ability to allocate spots directly as an internal endpoint for administrative reasoning, as pointed out later if a spot were being "painted over" as an example and out of commission. Forcing admin to mess with the sql code to block off spots can lead to serious problems later down the line. I also think that the code to select spots should be possible lambda based, allowing for better allocations later, or even on a per-garage set up (a garage in one location might have lower numbers next to the front door versus another garage with higher numbers next to the door). Speaking of doors, knowing where the customer is going within the location might help facilitate a better spot allocation (for example, in an airport). I guess it's easy to figure out the flaws in a system sitting in my comfortable chair watching it unfold versus while being within the interview itself....but those would have been my concerns going in, especially when Amazon attempts to API everything anyway, so anything made would have to be interchangeable and universal.
@kylekeenan3485 Жыл бұрын
You are right but in reality you don't spend 30 mins talking over the design for an entire car park booking system. You would most likely do it over a couple of days or weeks, and the requirements gathering from the customer would have provided you with much more information to work with up front.
@praveensg2 жыл бұрын
I would have added a caching layer for reads than introducing multiple Read replicas with a load balancer on top. It's a lot more complicated to add read replicas and route reads to the LB versus just a simple lazy load from cache (could even sit on the backend server versus a dedicated distributed cache). Good overall exercise. Smart guy.
@blipojones21142 жыл бұрын
What would go in the cache tho, the next 5 days of availability for all spaces? I would think eventually we would have to eventually just go back to a read replica since we could be looking for availability at any time of day, over possibly a 6 month period.
@yardy882 жыл бұрын
@@blipojones2114 who books a parking space 6 months in advance? This seems somewhat strange to me.
@blipojones21142 жыл бұрын
@@yardy88 people who plan a holiday, >6 months in advance is not uncommon, and need to leave the car in the airport in a reserved space for the duration of the holiday. but lets just say 3 weeks, to make it simpler, maybe a birthday and driving friends into city, leave car for the night there, pick up next day.
@Hgy2d Жыл бұрын
Helpful! Watching this to prepare for my first system design interview today!
@gordonli49462 жыл бұрын
in spot table , why not as key? same idea as theater 1 has seat 1, theater 2 also has seat 1; why need vehicle table in this design? the interviewer actually asks for the design of the reservation/payment system; why /login is an internal endpoint?
@punstress7 ай бұрын
There can be more than one reservation for the same garage and spot - not at the same time of course, but same day very likely.
@venkatasundararaman2 жыл бұрын
Free spots should be an external endpoint in my opinion. This will help to display all the available spots to the user and the user can then choose the spot like we do in air planes.
@pb7379-j2k3 жыл бұрын
Is it typical to get into the deep details like the "varchar" vs "string" property types in the tables? Very implementation detail-y
@devpragmatico2 жыл бұрын
I would say no. However, sometimes the interviewer will want to get into the details of a certain part of the system and if you can answer correctly, you will get bonus points for that.
@blipojones21142 жыл бұрын
Ye that seemed weird to me, it went into detail on things i wouldn't go into myself. I'd would have gone into detail about how to determine actual availability for a specific garage, for a range of days i.e 5th to the 10th
@FainTMako2 жыл бұрын
No, nothing about this interview was normal. His responses would not fly well with an interview and its just now how you start mapping out a new product
@jiayanguo3802 жыл бұрын
Overall, this is good. But, it is not covered some important parts. For example: Serializable isolation, for example, if two users both try to reserve the same spot at the same time, you need serializable isolation in this case. For the payment, that is not how usually, it works. we usually reserve first, then pay later. So, you need a state to track the reservation status. and the reservation should keep only a specific period if not paid.
@DaCoste Жыл бұрын
That was a very nice mock interview, thanks a lot! However, Would like to add that it would have done to talk about payment process, because we have an 3rd party payment and internal record of the transaction, so: - How handle it? - Who will be first, our DB or the external? - What happend if the external is nor available? - Atomic transaction? - Sync or async comunication with external? Thanks for the good work! :)
@tryexponent Жыл бұрын
Hey Julian! Thanks for sharing your thoughts and your kind words! :)
@d4veg2 жыл бұрын
Good video. I don't understand why *login* and *create_acount* are internal endpoints though.
@rliy0013 жыл бұрын
Would the system be called "Reasonable Parker"? Or "Parking Reasonable"?
@fitybux46643 жыл бұрын
How about "making users have to download an app when before they didn't have to"?
@dev-skills3 жыл бұрын
00:00:44 - I have never seen a parking space where reservation is possible. It would have been better if we just allow vehicles to come in based on whether there are parking spots available.
@DiwasTimilsina2 жыл бұрын
I like the way he laid out the api endpoints. I am totally stealing this style. Thanks!
@arianazin54192 жыл бұрын
He should have described (and the interviewer should have asked him about) flows of different scenarios: someone comes in and wants to reserve a spot. What happens first? What endpoints are hit? What records are written to the database? This is a crucial part of the interview. The video clearly lacked that.
@thsieh060612 жыл бұрын
What do the "Internal endpoints" refer to? Do they refer to the the endpoints of the internal microservices of the system? Or do they refer to endpoints that the system expose to the network, that are intended to be called only by the webapp or mobile app?
@itisyerdad2 жыл бұрын
My question to you, Tim, would be what do you think the public endpoints mentioned are?
@NainoaFaulkner-Jackson2 ай бұрын
This is informative, but it's much more of a monologue than an interview. I don't know how you guys structure these, if he knew the answer already or not, but it really feels like he's just stepping through a solution he already knew, as opposed to working through a problem in real time.
@tryexponent2 ай бұрын
Thanks for the feedback!
@pinkweb580Ай бұрын
Also you need parking plot weight sensors which must integrated with app to makes fully automated system!
@bebe7C93 жыл бұрын
I don't have any experience with this kind of interview but shouldn't he start off with plotting services and how they connect to each other? Then he can proceed to explain them in detail >>if needed
@varshard03 жыл бұрын
Agree. I think he only think in monolithic architecture, which is fine for the scope of the problem, but I still think beginning with modules instead of jumping directly to endpoints is much better.
@freezefrancis3 жыл бұрын
The interviewer seems to be not challenging the interviewee enough. At the end everything looks "reasonable". Pretty boring interview in my opinion.
@alexey48543 жыл бұрын
Totally agree, only one question from interviewer which is about data consistency. Interviewer learned very little about candidate by not asking more questions or challenging. Also candidate looked extremely bored, burned out. Would get rejected.
@cagmz3 жыл бұрын
Agreed. There was very little pushback by the interviewer, and I think this caused the interviewee to go on a tangent with some feature creep (ie accounts, which weren't part of the requirements).
@absmand3 жыл бұрын
@@alexey4854 Damn thats harsh
@1NightInParisOfficial2 жыл бұрын
An intrview is not to judge your ability to entertain and not be "boring". It is to test your knowledge and problem solving skills for a certain task or number of tasks. I know we like to think of KZfaq as an entertainment source, but not every video is meant for entertaining, some can actually teach dumb people like you what type of problem solving, and intelligence it may take to land a 200k-400k/year salary position. People like you are trolls to smart and succesful people. FYI.
@freezefrancis2 жыл бұрын
@@1NightInParisOfficial i think you don't get the point. This video just looks like it's done for an entertainment purpose and not reflect a real interview. I myself have taken a lots of interviews and you should never let the candidate make a design choice without challenging him/her and never let him go out of scope discussions. That's how you get smart people into your company, otherwise you end up with storytellers.
@jrhager843 жыл бұрын
My dumbass at 1am watching this: 'Zipcode? That sounds fancy!' Brain catches up when he shares the screen... 'I'm an idiot.'
@MrQsam2 жыл бұрын
the interview was pretty reasonable.. :P
@whatTheFcuk93 жыл бұрын
Please make video's like this for all grokking system 25 problems
@RajaSekharaReddyKaluri3 жыл бұрын
Same would have taken a month or so in a company!
@janlanik26602 жыл бұрын
This was more like "Design and international chain of parking garages". He didn't even ask how many garages how many users. For one garage you would just need like one application server + mysql.
@user-pw7um8wg5j3 жыл бұрын
Do we really need multiple DBs for read/write if there is only 2K spot at most? Maybe one backup replication should be fine?
@Sairysss13 жыл бұрын
Yeah, multiple read replicas definitely seem like over-engineering. One backup is totally fine for this case.
@pdomicioex2 жыл бұрын
Had the same idea, it is too much for such a small amount of requests. he did not need to do the responsability segregation on this case. BUT if he had made the questions about future escalation... maybe he was already thinking about an future update but did not made it clear to the interviewer.
@johnnychang34563 жыл бұрын
Is it better to start with DB or API endpoints? For me I feel like starting with DB or resources is better in terms of framing the structure.
@michaelfulton10802 жыл бұрын
I think the endpoints define the behavior of the application... you can use the endpoints to inform how the DB should be structured since you know how they will be accessed.
@bionic_batman2 ай бұрын
That was pretty reasonable solution I reasonably enjoyed watching it
@doomkoala2 жыл бұрын
I really think you should be able to calculate the price of a booking without needing a reservation_id. As a customer I'll want to know how much I'm paying *BEFORE* I make the reservation.
@abcxyzeldorado3 жыл бұрын
Which tool are you using for drawing tables and blocks?
@efimovdk3 жыл бұрын
whimsical.com
@yumindev2 жыл бұрын
You need a status for reservations, such as pending (not paid yet), confirmed (paid), expired ( not paid for a long time, such as 15min ), and fulfilled (paid and it has passed the end time). And you need to allow users to extend the end_time.
@wieslawpopielarski8974 Жыл бұрын
cool shelf full of dumbbells in the back :) seriously very nice example. I've always failed system design step actually because the expectations of interviewing person weren't clear for me. Now I know where to put the focus on. Thanks.
@animaltrainer88 Жыл бұрын
I know you guys are trying to sell this, but this doesn't sound like a system design interview. It looks like it's pre-studied, pre-arranged and very mechanic exchange between the interviewer and interviewee. Real system design interviews are not like this. An experienced interviewer doesn't go with standard , predictable questions , instead he/she will give small challenges along the way to test your analytic skills, your knowledge and how you deal with small changes in the requirements. Some interviewers even try to bring stuff from your resume. They want to make sure, you are not there just hacking the interview, you actually poses the knowledge and the experience for the position.
@user-ko7oo2qg1g3 жыл бұрын
Internal endpoint: create_account and login??
@MrUltrakitsch2 жыл бұрын
We only need the developers to be able to use the parking. It seems reasonable.
@stevezes3 жыл бұрын
Oh wow, they asked me this exact question at Amazon
@tehseensajjad10033 жыл бұрын
idk dude, they just kept asking me "How did you get here? where is security?" as if i know where the fucking security is..
@arvind314593 жыл бұрын
@@tehseensajjad1003 😂😂
@kibuikamwangi173 жыл бұрын
@@tehseensajjad1003 😂😂😂 which tool did you use for design...
@coolerkid99992 жыл бұрын
It's reasonably reasonable to make the reasonable assumption that this video is pretty reasonable
@SL3DApps2 жыл бұрын
This guy seems like a pretty reasonable person.
@user-oy4kf5wr8l3 жыл бұрын
this guy just looks so confident and so good at tech, i dont even need to watch the video lol
@yagizcagan3 жыл бұрын
he just looks it unfortunately.
@townegr3 жыл бұрын
This was very informative. Which web app is the interviewee using to demonstrate his system design?
@Bweeeebweeee3 жыл бұрын
I believe it is Whimsical !
@arielguzman28753 жыл бұрын
I find this channel more useful than the one that keeps spamming with ads. Like this if you know who I’m taking about. They are annoying and I don’t particularly like the person making the videos. I’ll leave it at that.
@koraytugay2 жыл бұрын
How does one insert garage, spot and pricing data in the first place? Will a garage have operation hours? Will there be subscription options? Discounts or dynamic pricing based on date/time? How does a user list available spots for a given date/time? Honestly I do not really understand how this architecture would work.