Uber system design: mock interview walk-through with Dima Korolev (ex-Google)

hello thanks for joining us for another system design mock interview uh first just a quick reminder if you are preparing for an interview then do check out our platform IGotAnOffer. com where you can find prep materials and you can also get onetoone coaching with ex-FAANG interviewers to help you nail the interview and get that job uh okay my candidate today was hired by Google after he was top coder of the month on algorithm track of top coder he also scored in the top 50 in the final round of Google code Jam um and since then he's done all sorts of things he's become one of the most interesting people online talking about system design and related topics um he's also a host of the YouTube channel SysDesign Meetup which you are welcome to get involved in yourself um let's bring him on Dima, thank you so much for doing this interview with us today good to be here thank you Tom I'll do a lot and I do have tons of pleasure and satisfaction from having people become better engineers and pass interviews with my callers so let's record this yeah great thanks for doing this and uh yeah demr is going to um play the role of the candidate but um he loves kind of helping people get better interviews and get better at system design first and foremost um so he will kind of step out of character at some points during the interview and to give you tips on what kind of considerations you should be making um okay that sound about right anything you want to add or should we crack straight on excited let's do it okay well dimma um the question I wanted to ask you today is how would you design Uber all righty well we start from certain requirements to make sure we're solving the same problem um usually in an interview there's a section called f FRS and nfrs functional nonfunctional requirements personally I don't necessarily like these terms that much but they do help so let's talk about what we need to solve for let's first not forget that Uber is a decided Marketplace so we have uh writers they B wres um basically if I'm a rer I am at Point a or I plan to be at Point a right now sometime soon maybe in the future and what I do is I use the app to call a cap to call a car call a taxi call an Uber to get from certain point B from A to B now or later um there also are the drivers which is a totally different part of a conversation because Uber again is a two-sided Marketplace so there no let's put aside the conversation about contractors versus full-time employees basically we we're going to like not touch regulation we got a bunch of people who have signed up for the platform so that they can be given rights I assume they pass all the background checks and they are allowed to do so and they also have the app open they do drive people from A to B um and uh so to me the most interesting part of uber is how to connect these two because solving for only this only writers or only drivers is not as fun as doing the whole thing as closing the loop but for the sake of completen let's talk about what the writers can do um well book a right from us a GPS of course from the way so that I can book the right from where I am right now or from a given point provided Point uh I can uh set custom time I can change the right Midway I can cancel it before or Midway there are tons of issues to worry about when it comes to like if it's an airport transfer pickup certain pickup points proper terminal locations if there is a parking lot to enter uh that's a big problem itself uh I'm not sure we need to go there but I need to put it here pick up drop of points Al to be honest this would be shared requirements and also the important thing here is that we have ratings

um and when I provide right so the way it works I think is uh when I'm the WR when I'm the driver I start my day I start my shift or what not I I'm back in business after lunch and uh I open the app and I Mark myself as available which is kind of my first requirement right out of business one hold and then what needs to happen is Uber is a company doesn't request rights other writers do so what happens when I'm marking myself as available U I'm going to start with s I'm going to call them bids the requests to be the request from particular writer to be taken from point A to point B I should also add here that uh we have different car types x black uh large and pets or whatnot children and I should also add that uh number of people can be different so as a writer of course I Mark myself available in a particular car the system knows that the system knows I'm driving like a Mercedes-Benz E-class which means I can take let's say up to four people as a driver you mean all yeah as a apologist as a driver yeah you need to just change that it says Rider just for oh thank you just not to confuse the viewers yeah you're absolutely right so do not confuse the viewers writers drivers so what happens with there's a separate conversation behind the scenes that has to do with the price uh price creation uh we need to talk about this eventually I don't think it's the time is right now but there is a there's a price it's in the shareed requirements price setting engine plus search pricing is a very clever idea it's that if we have a hot Marketplace if it's Christmas or if it's some I don't know large sport event uh because we have so many so much more writers than drivers the price gets higher so that the drivers make extra money and the market works out this thing but from what I understand from what I know Uber by Design does not let people bid on prices Uber says the price itself so it's other platforms probably let you like put the amount as the writer and potential as a driver until the orders match like in the order book but with Uber it's fixed price computed by the platform given the current conditions uh what's important here is that when I am the driver and I receive the bid I'm not entirely positive I've not it's been a while since I've seen this interface from the inside but I don't think the driver knows a lot about the right because I think from the product perspective there used to be uh there was a failure mode when if you want to go to a certain region where drivers don't want to go to you cannot order a car there order a uber there so I think what they would tell you as a driver is you need to pick up somebody at a certain point it's going to be on the map on your phone so I know how far it is chances are it's going to be sent to me while I'm driving a current passenger so that Uber is a platform really wants their drivers to be driving full-time so when I'm completing the ride my phone will start buzzing me with potential options and I think I don't think it's going to tell me where or is the next potential writer going but it's going to tell me if it's a short ride or a long ride and I also think there's a big important feature which was ultimately introduced and people loved it drivers loved it when they can Mark themselves as going home so that on the one hand you cannot I'm sort of making this up but it's fine on the one hand I mean I I have some knowledge but I'm also making indicated guesses the way it works is on the one hand you don't want to penalize the writers who go to the area where drivers don't want to go they would be embarrassing and insane so the way works is we the platform Uber the platform does not tell that

driver that this potential customer potential Rider wants to go to certain region they don't want to go to but at the same time when it's like late in my shift and I probably plan to be going home I can hit the platform that hey I would much rather be going towards that direction so if I'm living in a town and I'm like north of it because that's where the airport is I can probably start marking myself as please take me to the rights home but not Vice person so on heading help mode yeah so receive pickup location time most often now um how long the right is PL to be how far and uh yeah I guess that's it how many people maybe doesn't matter but not too much all right so now if this makes sense I think it mostly does so far um let's talk about what we're actually optimizing for these for function requirements um I think the way I would put it nonfunctional requirements my goal the objective is to keep the writers the drivers busy oh I think there also would also be a rating my goal is to get the driver Vis that's the number one priority from what I understand about the right share in business it's always the provider of the service the drivers who are in shot Supply so whatever I can do algorithmically design wise um financially to keep them more engaged especially when it's most needed by the writers I should be doing that in terms of CIS design for from the algorithm setpoint the most interesting part I think would be to improve the algorithms of suggesting which drivers get routed to which writers because that's my bur and but that's my algorithm so I'm thinking out loud here how to approach the problem of logistics so like let's focus on the on the mention problem uh write driver full disclosure I have no idea how it works I'm going to be making guesses which is probably what you guys should be doing in an interview so let's start to postulate it from first principles um when I don't know what to say I will start saying the most obvious things and go with the flow the most obvious thing is that imagine I'm the writer I'm taking my phone I'm going to call they up I expect some nearby who are either Idol or are about to complete their trip I'm expecting them to be notified of my request of my right yeah request um in practice I'm almost positive the way it's going to work internally it's that my write request is not sent to all the drivers in the area at the same time I don't really want my drivers to feel like they had to compete for the right I don't feel like I don't want to design the system so that from the product standpoint from the ux standpoint if I'm the driver who wants to make money I'm distracted and frantically Ty in yes accept the right once uh once I'm about to drop off this particular passenger and I'm looking for the next one in fact now that I think about it one obvious thing would be maybe a lot of drivers would actually enter this automatically accept rise mode I'm not sure if Uber works this way it might even be against certain regulations but if I'm the assistant designer I would argue that let's extend this also consider some automatically accept rights until I don't know t plus 2 hours 5m. so obviously if I'm the driver I have a good rating car everything fits U the platform if the platform knows my default is to accept the right it's like with Airbnb if you have instant look if this driver yeah I could put this

here if it's a platform I know that the writer has request at the right and there is a driver available in their vicinity who's idle or about to be idle soon and who has this instant book feature on I will just send this writer the this request and assume that the request is taken at the start of the interview you want to clarify the scope of the question with the interviewer as DEA probably should have done here before jumping in for example did we want to focus on just the ride Hing app or include Uber Eats Etc are we trying to design Uber as it is now or a new improved version if you're going to make assumptions clarify them with the interviewer Dema covers the functional and nonfunctional requirements in a lot of detail if he was interviewing at Uber this would probably be the right way to go because it's a very product first company and an Uber interview viwer will want to see that you're capable of anticipating specific product needs and adapting accordingly if you are interviewing at another company such as Google you'd probably want to be a bit quicker on the requirements to give yourself more time on your design I think QX WIS I would say I would do it like this so we're going to be talking about the algorithm plus ux and then we'll start drawing stuff uh um so from the way I usually do it is I would say like life of a right what what happens to the right as it progresses through the system first of all it's requested by writer then the system starts looking for a driver um let's design so the main idea here is that I don't really want to be sent in the same R to multiple drivers currently simultaneously because I don't want them to be distracted so even if uh let's say there are no instantly bookable drivers and there are five drivers around me I would still not want to send a request to all of them simultaneously because as a driver once I'm seeing the invitation to accept the right let's say I want this driver to have 10 15 seconds well 5 10 seconds to accept this right and they don't need to compete with each other so like if I'm the driver I'm dropping you off and someone else is about to take a ride from near where I am and I'm seeing the notification hey there's a person next to us Mark who needs a write as a I would like to design the ux and the flow so that once as a driver I see this notification I have the next let's say 7even seconds to decide if I accept this right or no for the next 7 seconds once it was sent to me this request is potentially mine it's not being routed to any other driver so either I accept it within let's say 7 seconds or I don't in which case the system finds the next potential driver so let's say we're going to have a two State two- tier process if instant book not available Pi a driver nearby M AI for selection send them the request wait I don't know 7 Seconds go to up find driver and be nerdy here if a driver is found If a driver who accept it is found go to peov so imagine there are no instantly bookable drivers yet I pick a driver I send in this D request wait for 7 seconds if no confirmation within this 7 seconds I'm going back to here in which case I'm looking for the next driver and instant book gets priority if an instant book driver is a varable nearby I would say same thing but I give them like four seconds that up seven if no explicit rejection is this

idea clear I just made this up it could be totally off but my point is that if you have people who are who are in this hot standby mode and they committed to accept every right I give them like four seconds to say no and if those guys aren't available I book a person who is not autoc confirming and I give them 7 Seconds to confirm now we get to the pickup mode um so to be honest in terms of sis design our job is mostly done here pickup is pretty much Google Maps navigations or ways or Apple Maps I don't think we need to design this we can use a third party app of course if we're a company such as Uber we have our own mapping technology and uh driving skilles what I serving capacities what I think we should mention here explicitly is the location is shared in real time moreover maybe tweaked to allow for uh traffic lights uh curb site pickup details Etc because I can totally imagine the first version of uber to be using let's say some standard Google Maps application and then I can totally imagine some standard is failure modes when let's say tiny road is one way and you probably want to be picking up the writer like 10 meters to the north because that's where it's easy to pick up this person so it's a separate conversation I don't think we should go there it's a bit too low level but fundamentally in the pickup mode until the match has been confirmed until we know both of the GPS uh coordinates of both people of both phones and until we know that the driver has started the right we're still on the pickup mode uh can still cancel from either side might be for a Fe and U we in this case if it cancel go back to the starting point once approved once the right is confirmed go to INR note confirmed includes but is not limited to GPS manual confirmation by the driver perhaps a code I know there's a feature when oh uh uh in certain locations in certain jurisdictions you don't really trust people to trust each other so the platform need to confirm that it's actually the correct Rider got into the correct car and the way Uber solves for this is they have a code like a four-digit code or QR code so the writer needs to share this with the driver and only once that is confirmed the WR can start um yeah I think this is mostly taken care of I could go on with the part where you like Liberty or something but I think we're good enough what do you say what would you say shall we get to Dr let's start designing yeah I think we we've covered enough there um do I have oh these are apps do I have pictures okay fine I have a rectangle you work at mirror so you should have everything right I know right well it's a personal account it's a free version I have a lot more okay Labs enabled so um I'm going to start from the writer which is the user because I think it's where the flow mostly it's where the more most intense flow happens all right s design diagrams and boxes there are many ways to approach this and honestly I it's been a while since I was doing this as a candidate but a lot of times so the first high level question to ask is are we using any cloud provider like Amazon a US Google Cloud Microsoft Azure something else or are we totally bare metal like our own Hardware a good design is of course agnostic to this but it's worth mentioning that so I'm going to do something like this I'm going to have a dashed angle should be far thicker by the way yeah that's like my

cloud misclick uh the way it always happens the first box inside this thinky is a low balancer a lot people a lot of people Miss what low balancers actually do so it's a cluster which is traditionally denoted by having a couple of them yeah lb cluster I think I can s it back uh the way it works is my request hits one of the instances of this loow balancer can make it thicker um in the case of uber it's not that important because extra let's say 2300 millisecond latency extra like 3 seconds would not make things very different but realistically what you want to do is you want the request from the user to enter your private Network as soon as possible so lot balances not are not only used to sh your backend servers so that you can add more of them they also serve to make sure that they ENT use your device the request from there enters my system as soon as possible and whatever Network calls happen behind the scenes they happen with my own network which is controlled by me which is low latency High throughput far more reliable that's what w balancer does here then it would fundamentally uh there's a big thing to say to be said here about uh G sharding I'll get there in a moment so fundamentally I would say like hypothetically this could literally be something like uh you can do it text this could literally be api. uber. com hypothetically that's the resource where the request comes to if if it's HTTP is of course hgps to be safe and secure to be not interceptable at least not easily interceptable now behind the scenes internally it should still be next to the arrow behind the scenes internally what happens is I would argue uh for many reasons low balancing and regulation different cities have their different have their own uh shs have their own specific sets of servers to serve the cities so it's like a per location Uber server what I'm doing here is I'm starting to get some work of routing the traffic done on the low balancer level because once you once the writer once my phone talks to law balancer first of all the phone knows where I am I assume there are some GPS coordinates I so if I'm in Austin it knows I'm in Austin if I'm in Singapore Singapore so the request of the law balancer even if it hits the same end point the same high level top level end point there's enough metadata for the law balancer to already decide that I'm drawing multiple of these because they also shed they know that the request would go to let's say um Austin I'm not sure Austin has Uber by the way so we can say it's there wasn't there was a new article a couple years ago that wasn't that is it doesn't so let's say it's New York and let's say keep waging this thingy and let's say there is something else which is San Francisco why not let's say it's Brin because we're International so the lot balancer at the moment it needs to make a decision where to pass this request to it can decide which which Uber location it goes to and there could be like in Europe there could be gdpr rules so for example per location data for burden cannot leave burden not leave Germany um I cannot comment on this right now I what so far the only thing I'm saying is that the moment the like my request my tab gets to the actual backend service here it's already tied to a particular location I think it's fine now this is a tricky part when people draw multiple things multiple boxes like I did here it means a couple things one thing it means is that if one of them dies the system is still up and running that's called high availability that's called resiliency that's

called durability well durability is mostly about not losing the data but still we need multiple of this that one of them can die and then once we commit to having multiple notes um it's a very delicate conversation how to proceed here because in terms of the system design architecture logically we can treat this as a single box and then decide how to best make sure it runs in a way that is highly available so nodes can die but it's still functional and durable so that once no once nodes die they don't lose any data so let's pretend for a moment logically that the whole Burly is served by a single instance of an Uber server for buring uh as a high-profile engineer I would actually go as far as saying that it's not impossible because the total amount of traffic to This Server when it comes to okay that's this deserves this warrant's drawing you have the so-called Riot path which are the mutations State changes and you have the read path that's immutable request for example when I'm just opening the app I really I literally want to see how many cars are there available I don't need to go to the right path I can go to the read path and read path is super easy to scale because that's what that's where strong versus vention consistency comes them to play read path can be eventually consistent if I literally open the Uber app to see how many cars are there around me if my data if the data I'm seeing is 3 five seconds behind heck even 30 seconds behind the product still doesn't suck it still fulfills all the requirements so the truth is that this is super easy to scale because it can be eventually consistent where as the right path can be eventually consistent the right path is where potential data races collisions happen on the r path if both of us open the app in the same location and we see slightly different pictures that's okay on the right path if both of us order right we get to different servers here you get to server a I get to server B and somehow these servers are not in line with what's going on and the same driver accepts AR rise from both of us that's a disaster that's a catastrophe that's what should be prevented so logically the right path is where this single source of Truth sing singular like mut slog so to speak synchronized section that's where it happens uh so I'm going to put it here and say should be synchronized single source of Truth and so one of the most difficult problems of system design is how to build synchronized s of Truth systems that are distributed but logically for now we can pretend there's a single machine and again as a high performance person I know it's possible if you take all the read path ques this these guys if you take them out of scope for now if you if you pretend there is enough machines that are only eventually consistent they can be behind the world time they cannot be up to date they might be like 5 Seconds 10 seconds 15 seconds behind the actual state of the fleet uh we ignore them for now they just work that's not difficult for the right path I'm going to claim that the total number of requests for new rights per second within the whole city of burlin is going to be quite small if you look back into all the state transitions so you go to we have pickup mode find the driver mode then we get the INRI mode etc then you can have to confirm the right and you may like leave a tip if you look at all the state transitions that needs to be correctly synchronized with one another that need to be respected the invariance such as no writer can no driver can accept two writers at the same time I'm going to claim that for a single C of Burling the number of mutating cures per second is actually quite small it is certainly way under one way under 1,000 I just cannot possibly imagine that on the right path in terms of synchronizing drivers and Riders you order more than one 1,000 rids per second so that's actually something one machine can handle uh in practice there will be more complexities here let me try to explain this in this limited amount of time we have left in practice is so the r path is a picture of all the cars available so to speak the right path is

the right wrer to driver matching State machine synchronization we also have something in the middle which is synchronizing specific data uh the data specifically particular right let me explain that's important uh I believe Uber has this feature share my right so I can as a writer I can request a WR get matched to a driver get matched with the driver get into the car is a right to the airport and I want my peers my wife or what not to do not be worried so I can share them I can send the link with them right through the Uber app so that they can watch in real time where my location is of course internally even if you don't share your right Uber backend Services absolutely do know where every driver Rider pair is the point is this potential component this guy sees a lot more traffic if the state changes such as right requested right canceled Right started right ended for these I believe the traffic would be quite small for the whole city in New York it's likely under three digits maybe low four digits for this the for the data specific to individual rights the QPS is far larger because like in a perfect in a simple terms you can imagine that let's say every five or 10 seconds the car the driver uh updates their position their coordinates connecting to the server in deck so the traffic here this is the most important part thing to keep right this is where conf can have this is where we need to maintain the invariant when the same driver cannot pick up two Riders this here the traffic is manageable by even a single machine here we have a lot more traffic even if it's let's say every 5 Seconds there's a beacon from every single uh driver currently driving for Uber or waiting to pick up someone and for every single Rider who is at least waiting for the right or in the right that can easily be thousands of this driving life so you can easily get tens of thousands of requests per second here but the trick is for this part you don't you cannot potentially have the data from one right colliding the data from the other right there's no conflict there's no path there's no room for conflicts there's no confusion you can break your your logical in variance here but not here so this basically what I'm drawing right now would be logically speaking a different subcomponents of uh of this per location Uber server so this is a fleet of servers I've ploted a couple of them I would argue that in practice for this logic but let's actually let's start from let's start botom up for the read path you can add as many machines as you want they just subscribe the feed of internal updates and uh it's like a CDN more or less to get snapshot of which cars are currently available in berl you get to one of many of these notes and you get the data that is somewhat accurate you just scale this as necessary I would argue there could be dozens of them maybe five to 10 for Bry maybe 15 for New York maybe 50 or 100 if you don't write your code correctly but that's a large number for these things you need as a large number of them too but each so these notes are all identical in logic they all interchangeable they're all funable if one of them dies you just replace it by a new one uh they all serve the same purpose and have the same data for these logic um if one node dies what happens is you start the traffic from your writers drivers and active rights you sh this traffic so that a particular data point in a particular time goes to a particular server you can use consistent hashen to send it to two or three machines just to make sure if one dies they is lost but honestly that's not important because if a machine dies well what's the worst that can happen for the next I would say half a minute you lose track of this big and keep alive messages of where the driver is no big deal on a company scale so this is also straightforward although you need to work on your sharting properly for this part you need to be super careful if you're a ninja engineer if your Uber is a startup that just need needs to launch somehow I would sincerely suggest that we just have a single machine for the whole buring that handles this if it dies until it TR starts or until a new machine starts on a backup for a couple seconds no new rights can

be requested no new rights can be confirmed or canceled or whatnot but in practice if you're if you are the big Uber itself you don't do it on a single machine that's too dangerous you have a few of them the standard technique is to use data rections have a have an odd number of machines stand traditionally would be three or five so that they always are in touch with each other they always know which one is the main one who whose word matters most in a democratic setum so that if one of these machines dies if it's not the leader that's okay it's it's replaced and kept up to date if the leader dies within a split second another leader is elected and they guarantee that all the invariant we need to respect are being respected that's my high level diagram DEA has laid out a very convincing highle design and explained his thinking clearly throughout one potential area of improvement is at senior level a lot of focus is put onto protocols dimma mentioned https in relation to the connection from the user's phone to the load balancer and Beyond but he didn't mention web sockets he would have done well to mention there should have been a persistent connection opened from the driver's phone and the rider's phone sharing the location coordinates using a single API call to achieve this would have been wasteful yeah that's uh that's interesting I wanted to uh ask you what metrics are you going to be tracking here like how know if the system is behaving as it should do oh that's a big question there are tons of directions ways to postulate the question actually so like bottom up as an engineer I want to make sure that my system is up and running so I would look at the traffic numbers everywhere traffic numbers here traffic numbers to every single location traffic numbers from within internal systems to all these components all these three if any of them drop something is wrong that's something I can totally monitor myself as a higher level C designer I would also argue we need to track user facing metrics I want to know how many rides are currently taking place I would imagine the office like imagine berlan has an Uber office I don't think it's the case but it doesn't matter I would imagine there's going to be a large screen to monitor real-time metrics with tons of charts it will be like active real-time number of riots happening right now there will be like this daily sine wave because there is more at night than in the afternoon and if suddenly it goes below what you would expect or above you this should trigger an alarm an alert somebody should look into this I would look into the length of the rights if the traffic pattern has changed I would look into the ratings of drivers and writers are we clearly like I will not deteriorate in performance for the end users I would absolutely look at more fine grain metrics such as like average distance from the rider to a driver average pickup time because in practice this is a very high level picture in practice there's going to be tons of a testing behind the scenes if my engineering team has designed a new meion algorithm that is presumably making pickups faster chances far is being a tested for parts of drivers and I want to see how it performs how it behaves so they can make a decisions on how to roll it out and went so yeah tons of cool stuff thank you for a good question yeah thanks for the answer um also yeah just before we wind this up um are there any other kind of features that you think might be interesting to add and how would they affect your design um yeah let me reflect let me look back at this as I slowly exit the mode of someone who was interviewed and I enter the mode of the like in hiring Committee Member um I think I've tried to give your listeners the best possible experience of seeing how the real interview looks like in practice if I'm being an interviewed like this I would absolutely ask what are we designing for real because nobody designs Ubers these days from scratch either it's a smaller startup so that it's not a dup a replica of uber but rather some more targeted news product I don't know maybe it's a Richa pickup maybe they are allowed to use pedestrian roads maybe they have drones maybe they have extra regulations on what business Advantage they have compared to the Uber itself in which case the design should absolutely be focused on this particular tailored like tailored own mode on the other hand if you really need to design Uber well I can guarantee you as someone who's in the industry for a long time this is not how Uber looks like on a high level yes but as we all know from Twitter and Elon Musk high level whiteboard designs have little to do with what systems look like behind the scenes so for the interview conversation I think that's approximately what I would imagine

candidates should draw when ask this question but if I'm interviewing given I'm a couple levels above the senior staff level I will probably be having a more product first conversation I think I managed to strike the balance and actually talk about consistency about data flows about databases somehow but yeah it's a really big can of worms and if I can leave you with one thing here you got to read your interview you got to figure out what this particular compan is looking for Uber in particular is well known Uber is a company is well known for looking for product first Engineers if you actually talk to the to your interviewer about hey I need to optimize like curbside pickup I need to suggest pickup spots because that's where writers are more happy to be picked up compared to other pickup spots where they complain like they were honked at this is super useful this gives you tons of bonus points for Uber for other companies do your homework but yeah tons of ways to go from here Dema gives some very useful advice and insight here for those of you with interviews coming up so let's recap quickly be sure to clarify at the beginning what problem you're trying to solve in this case are we designing Uber or a new improved Uber for example generally the more senior your level the more product first your approach should be but try to figure out what your target company is looking for Uber is known for hiring product first Engineers but that's not the case at every company this is where doing mock interviews with ex interviewers from your target company can be very helpful you can do that with our coaches at IGotAnOffer. com Dima yeah I think we can finish it there unless uh there's anything else you want to comment on or any other advice that you want to give to the viewers um well I'm still in the excited mode so I would say one thing I did not do and you guys should is talking about databases I've deliberately voted the topic because the high level picture trumps uh the choice of like S no SQL and stuff like that but fundamentally yeah I do hope it's helpful please spend your time with you Tom and all the best hello really hope you found that useful if you did you can like And subscribe and why not come visit us at IGotAnoffer. com there you can find more videos useful Frameworks and question guides all completely free and you can also book expert feedback one to one with our coaches from Google meta Amazon Etc thank you and good luck with your interview