Design AlgoExpert
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: Are we designing the entire AlgoExpert platform or just a specific part of it, like the coding workspace?
A: Since we only have about 45 minutes, you should just design the core user flow of the AlgoExpert platform. The core user flow includes users landing on the home page of the website, going to the questions list, marking questions as complete or in progress, and then writing and running code in various languages for each language. Don’t worry about payments or authentication; you can just assume that you have these services workingalready (by the way, we mainly rely on third-party services here, like Stripe, PayPal, and OAuth2).
Question 2
Q: AlgoExpert doesn’t seem like a system of utmost criticality (like a hospital system or airplane software); are we okay with 2 to 3 nines of availability for the system?
A: Yes, this seems fine–no need to focus too much on making the system highly available.
Question 3
Q: How many customers should we be building this for? Is AlgoExpert’s audience global or limited to one country?
A: AlgoExpert’s website receives hundreds of thousands of users every month, and tens of thousands of users may be on the website at any point in time. We want the website to feel very responsive to people everywhere in the world, and the U.S. and India are the platform’s top 2 markets that we especially want to cater to.
Question 4
Q: Does AlgoExpert make changes to its content (questions list and question solutions) often?
A: Yes–every couple of days on average. And we like to have our changes reflected in production globallywithin the hour.
Question 5
Q: How much of the code-execution engine behind the coding workspace should we be designing? Do we have to worry about the security aspect of running random user code on our servers?
A: You can disregard the security aspects of the code-execution engine and just focus on its core functionality–the ability to run code in various languages at any given time with acceptable latency.
Question 6
Q: While we’ll care about latency across the entire system, the code-execution engine seems like the place where we’ll care about it most, since it’s very interactive, and it also seems like the toughest part of our system to support low latencies; are we okay with anywhere between 1 and 3 seconds for the average run-code latency?
A: Yes–this seems reasonable and acceptable from a product point of view.
Design A Code-Deployment System
Design a global and fast code-deployment system.
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: What exactly do we mean by a code-deployment system? Are we talking about building, testing, and shipping code?
A: We want to design a system that takes code, builds it into a binary (an opaque blob of data–the compiled code), and deploys the result globally in an efficient and scalable way. We don’t need to worry about testing code; let’s assume that’s already covered.
Question 2
Q: What part of the software-development lifecycle, so to speak, are we designing this for? Is this process of building and deploying code happening when code is being submitted for code review, when code is being merged into a codebase, or when code is being shipped?
A: Once code is merged to the trunk or master branch of a central code reposity, engineers should be able to (through a UI, which we’re not designing) trigger a build and deploy that build. At that point, the code has already been reviewed and is ready to ship. So to clarify, we’re not designing the system that handles code being submitted for review or being merged into a master branch–just the system that takes merged code, builds it, and deploys it.
Question 3
Q: Are we essentially trying to ship code to production by sending it to, presumably, all of our application servers around the world?
A: Yes, exactly.
Question 4
Q: How many machines are we deploying to? Are they located all over the world?
A: We want this system to scale massively to hundreds of thousands of machines spread across 5-10 regions throughout the world.
Question 5
Q: This sounds like an internal system. Is there any sense of urgency in deploying this code? Can we afford failures in the deployment process? How fast do we want a single deployment to take?
A: This is an internal system, but we’ll want to have decent availability, because many outages are resolved by rolling forward or rolling back buggy code, so this part of the infrastructure may be necessary to avoid certain terrible situations. In terms of failure tolerance, any build should eventually reach a SUCCESS or FAILURE state. Once a binary has been successfully built, it should be shippable to all machines globally within 30 minutes.
Question 6
Q: So it sounds like we want our system to be available, but not necessarily highly available, we want a clear end-state for builds, and we want the entire process of building and deploying code to take roughly 30 minutes. Is that correct?
A: Yes, that’s correct.
Question 7
Q: How often will we be building and deploying code, how long does it take to build code, and how big can the binaries that we’ll be deploying get?
A: Engineering teams deploy hundreds of services or web applications, thousands of times per day, building code can take up to 15 minutes, and the final binaries can reach sizes of up to 10 GB. The fact that we might be dealing with hundreds of different applications shouldn’t matter though; you’re just designing the build pipeline and deployment system, which are agnostic to the types of applications that are getting deployed.
Question 8
Q: When building code, how do we have access to the actual code? Is there some sort of reference that we can use to grab code to build?
A: Yes; you can assume that you’ll be building code from commits that have been merged into a master branch. These commits have SHA identifiers (effectively arbitrary strings) that you can use to download the code that needs to be built.
Design A Stockbroker
Design a stockbroker: a platform that acts as the intermediary between end-customers and some central stock exchange.
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: What do we mean exactly by a stock broker? Is this something like Robinhood or Etrade?
A: Yes, exactly.
Question 2
Q: What is the platform supposed to support exactly? Are we just supporting the ability for customers to buy and sell stocks, or are we supporting more? For instance, are we allowing other types of securities like options and futures to be traded on our platform? Are we supporting special types of orders like limit orders and stop losses?
A: We’re only supporting market orders on stocks in this design. A market order means that, given a placed order to buy or sell a stock, we should try to execute the order as soon as possible regardless of the stock price. We also aren’t designing any “margin” system, so the available balance is the source of truth for what can be bought.
Question 3
Q: Are we designing any of the auxiliary aspects of the stock brokerage, like depositing and withdrawing funds, downloading tax documents, etc.?
A: No – we’re just designing the core trading aspect of the platform.
Question 4
Q: Are we just designing the system to place trades? Do we want to support other trade-related operations like getting trade statuses? In other words, how comprehensive should the API that’s going to support this platform be?
A: In essence, you’re only designing a system around a PlaceTrade API call from the user, but you should define that API call (inputs, response, etc.).
Question 5
Q: Where does a customer’s balance live? Is the platform pulling a customer’s money directly from their bank account, or are we expecting that customers will have already deposited funds into the platform somehow? In other words, are we ever directly interacting with banks?
A: No, you won’t be interacting with banks. You can assume that customers have already deposited funds into the platform, and you can further assume that you have a SQL table with the balance for each customer who wants to make a trade.
Question 6
Q: How many customers are we building this for? And is our customer-base a global one?
A: Millions of customers, millions of trades a day. Let’s assume that our customers are only located in 1 region – the U.S., for instance.
Question 7
Q: What kind of availability are we looking for?
A: As high as possible, with this kind of service people can lose a lot of money if the system is down even for a few minutes.
Question 8
Q: Are we also designing the UI for this platform? What kinds of clients can we assume we have to support?
A: You don’t have to design the UI, but you should design the PlaceTrade API call that a UI would be making to your backend. Clients would be either a mobile app or a webapp.
Question 9
Q: So we want to design the API for the actual brokerage, that itself interacts with some central stock exchange on behalf of customers. Does this exchange have an API? If yes, do we know what it looks like, and do we have any guarantees about it?
A: Yes, the exchange has an API, and your platform’s API (the PlaceTrade call) will have to interact with the exchange’s API. As far as that’s concerned, you can assume that the call to the exchange to make an actual trade will take in a callback (in addition to the info about the trade) that will get executed when that trade completes at the exchange level (meaning, when the trade either gets FILLED or REJECTED, this callback will be executed). You can also assume that the exchange’s system is highly available–your callback will always get executed at least once.
Design Facebook News Feed
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: Facebook News Feed consists of multiple major features, like loading a user’s news feed, interacting with it (i.e., posting status updates, liking posts, etc.), and updating it in real time (i.e., adding new status updates that are being posted to the top of the feed, in real time). What part of Facebook News Feed are we designing exactly?
A: We’re designing the core functionality of the feed itself, which we’ll define as follows: loading a user’s news feed and updating it in real time, as well as posting status updates. But for posting status updates, we don’t need to worry about the actual API or the type of information that a user can post; we just want to design what happens once an API call to post a status update has been made. Ultimately, we primarily want to design the feed generation/refreshing piece of the data pipeline (i.e, how/when does it get constructed, and how/when does it get updated with new posts).
Question 2
Q: To clarify, posts on Facebook can be pretty complicated, with pictures, videos, special types of status updates, etc… Are you saying that we’re not concerned with this aspect of the system? For example, should we not focus on how we’ll be storing this type of information?
A: That’s correct. For the purpose of this question, we can treat posts as opaque entities that we’ll certainly want to store, but without worrying about the details of the storage, the ramifications of storing and serving large files like videos, etc…
Question 3
Q: Are we designing the relevant-post curation system (i.e., the system that decides what posts will show up on a user’s news feed)?
A: No. We’re not designing this system or any ranking algorithms; you can assume that you have access to a ranking algorithm that you can simply feed a list of relevant posts to in order to generate an actual news feed to display.
Question 4
Q: Are we concerned with showing ads in a user’s news feed at all? Ads seem like they would behave a little bit differently than posts, since they probably rely on a different ranking algorithm.
A: You can treat ads as a bonus part of the design; if you find a way to incorporate them in, great (and yes, you’d have some other ads-serving algorithm to determine what ads need to be shown to a user at any point in time). But don’t focus on ads to start.
Question 5
Q: Are we serving a global audience, and how big is our audience?
A: Yes – we’re serving a global audience, and let’s say that the news feed will be loaded in the order of 100 million times a day, by 100 million different users, with 1 million new status updates posted every day
Question 6
Q: How many friends does a user have on average? This is important to know, since a user’s status updates could theoretically have to show up on all of the user’s friends’ news feeds at once.
A: You can expect each user to have, on average, 500 friends on the social network. You can treat the number of friends per user as a bell-shaped distribution, with some users who have very few friends, and some users who have a lot more than 500 friends.
Question 7
Q: How quickly does a status update have to appear on a news feed once it’s posted, and is it okay if this varies depending on user locations with respect to the location of the user submitting a post?
A: When a user posts something, you probably want it to show up on other news feeds fairly quickly. This speed can indeed vary depending on user locations. For instance, we’d probably want a local friend within the same region to see the new post within a few seconds, but we’d likely be okay with a user on the other side of the world seeing the same post within a minute.
Question 8
Q: What kind of availability are we aiming for?
A: Your design shouldn’t be completely unavailable from a single machine failure, but this isn’t a high availability requirement. However, posts shouldn’t ever just disappear. Once the user’s client gets confirmation that the post was created, you cannot lose it.
Design Google Drive
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: Are we just designing the storage aspect of Google Drive, or are we also designing some of the related products like Google Docs, Sheets, Slides, Drawings, etc.?
A: We’re just designing the core Google Drive product, which is indeed the storage product. In other words, users can create folders and upload files, which effectively stores them in the cloud. Also, for simplicity, we can refer to folders and files as “entities”.
Question 2
Q: There are a lot of features on Google Drive, like shared company drives vs. personal drives, permissions on entities (ACLs), starred files, recently-accessed files, etc… Are we designing all of these features or just some of them?
A: Let’s keep things narrow and imagine that we’re designing a personal Google Drive (so you can forget about shared company drives). In a personal Google Drive, users can store entities, and that’s all that you should take care of. Ignore any feature that isn’t core to the storage aspect of Google Drive; ignore things like starred files, recently-accessed files, etc… You can even ignore sharing entities for this design.
Question 3
Q: Since we’re primarily concerned with storing entities, are we supporting all basic CRUD operations like creating, deleting, renaming, and moving entities?
A: Yes, but to clarify, creating a file is actually uploading a file, folders have to be created (they can’t be uploaded), and we also want to support downloading files.
Question 4
Q: Are we just designing the Google Drive web application, or are we also designing a desktop client for Google drive?
A: We’re just designing the functionality of the Google Drive web application.
Question 5
Q: Since we’re not dealing with sharing entities, should we handle multiple users in a single folder at the same time, or can we assume that this will never happen?
A: While we’re not designing the sharing feature, let’s still handle what would happen if multiple clients were in a single folder at the same time (two tabs from the same browser, for example). In this case, we would want changes made in that folder to be reflected to all clients within 10 seconds. But for the purpose of this question, let’s not worry about conflicts or anything like that (i.e., assume that two clients won’t make changes to the same file or folder at the same time).
Question 6
Q: How many people are we building this system for?
A: This system should serve about a billion users and handle 15GB per user on average.
Question 7
Q: What kind of reliability or guarantees does this Google Drive service give to its users?
A: First and foremost, data loss isn’t tolerated at all; we need to make sure that once a file is uploaded or a folder is created, it won’t disappear until the user deletes it. As for availability, we need this system to be highly available.
Design The Reddit API
Design an API for Reddit subreddits given the following information.
The API includes these 2 entities:
User | userId: string, …
SubReddit | subredditId: string, …
Both of these entities likely have other fields, but for the purpose of this question, those other fields aren’t needed.
Your API should support the basic functionality of a subreddit on Reddit.
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: To make sure that we’re on the same page: a subreddit is an online community where users can write posts, comment on posts, upvote / downvote posts, share posts, report posts, become moderators, etc…–is this correct, and are we designing all of this functionality?
A: Yes, that’s correct, but let’s keep things simple and focus only on writing posts, writing comments, and upvoting / downvoting. You can forget about all of the auxiliary features like sharing, reporting, moderating, etc…
Question 2
Q: So we’re really focusing on the very narrow but core aspect of a subreddit: writing posts, commenting on them, and voting on them.
A: Yes.
Question 3
Q: I’m thinking of defining the schemas for the main entities that live within a subreddit and then defining their CRUD operations – methods like Create/Get/Edit/Delete/List – is this in line with what you’re asking me to do?
A: Yes, and make sure to include method signatures – what each method takes in and what each method returns. Also include the types of each argument.
Question 4
Q: The entities that I’ve identified are Posts, Comments, and Votes (upvotes and downvotes). Does this seem accurate?
A: Yes. These are the 3 core entities that you should be defining and whose APIs you’re designing.
Question 5
Q: Is there any other functionality of a subreddit that we should design?
A: Yes, you should also allow people to award posts. Awards are a special currency that can be bought for real money and gifted to comments and posts. Users can buy some quantity of awards in exchange for real money, and they can give awards to posts and comments (one award per post / comment).
Design Netflix
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Q: From a high-level point of view, Netflix is a fairly straightforward service: users go on the platform, they’re served movies and shows, and they watch them. Are we designing this high-level system entirely, or would you like me to focus on a particular subsystem, like the Netflix home page?
A: We’re just designing the core Netflix product–so the overarching system / product that you described.
Question 2
Q: Should we worry about auxiliary services like authentication and payments?
A: You can ignore those auxiliary services; focus on the primary user flow. That being said, one thing to note is that, by nature of the product, we’re going to have access to a lot of user-activity data that’s going to need to be processed in order to enable Netflix’s recommendation system. You’ll need to come up with a way to aggregate and process user-activity data on the website.
Question 3
Q: For this recommendation system, should I think about the kind of algorithm that’ll fuel it?
A: No, you don’t need to worry about implementing any algorithm or formula for the recommendation engine. You just need to think about how user-activity data will be gathered and processed.It sounds like there are 2 main points of focus in this system: the video-serving service and the recommendation engine. Regarding the video-serving service, I’m assuming that we’re looking for high availability and fast latencies globally; is this correct?Yes, but just to clarify, the video-streaming service is actually the only part of the system for which we care about fast latencies.
Question 4
Q: So is the recommendation engine a system that consumes the user-activity data you mentioned and operates asynchronously in the background?
A: Yes.
Question 5
Q: How many users do we expect to be building this for?
A: Netflix has about 100M to 200M users, so let’s go with 200M.
Question 6
Q: Should we worry about designing this for various clients, like desktop clients, mobile clients, etc.?
A: Even though we’re indeed designing Netflix to be used by all sorts of clients, let’s focus purely on the distributed-system component–so no need to get into details about clients or to optimize for certain clients.
Design The Uber API
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask’
Question 1
Q: Uber has a lot of different services: there’s the core ride-hailing Uber service, there’s UberEats, there’s UberPool–are we designing the API for all of these services, or just for one of them?
A: Let’s just design the core rides API – not UberEats or UberPool.
Question 2
Q: At first thought, it seems like we’re going to need both a passenger-facing API and a driver-facing API–does that make sense, and if yes, should we design both?
A: Yes, that totally makes sense. And yes, let’s design both, starting with the passenger-facing API.
Question 3
Q: To make sure we’re on the same page, this is the functionality that I’m envisioning this API will support: A user (a passenger) goes on their phone and hails a ride; they get matched with a driver; then they can track their ride as it’s in progress, until they reach their destination, at which point the ride is complete. Throughout this process, there are a few more features to support, like being able to track where the passenger’s driver is before the passenger gets picked up, maybe being able to cancel rides, etc… Does this capture most of what you had in mind?
A: Yes, this is precisely what I had in mind. And you can work out the details as you start designing the API.
Question 4
Q: Do we need to handle things like creating an Uber account, setting up payment preferences, contacting Uber, etc…? What about things like rating a driver, tipping a driver, etc.?
A: For now, let’s skip those and really focus on the core taxiing service.
Question 5
Q: Just to confirm, you want me to write out function signatures for various API endpoints, including parameters, their types, return values, etc., right?
A: Yup, exactly.
Design Slack
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: There are a lot of things that you can do on Slack. Primarily, you use Slack to communicate with people in one-on-one channels, private channels, or public channels, all within an organization. But you can also do a bunch of other things on Slack, like create and delete channels, change channel settings, change Slack settings, invite people to channels, etc… What exactly are we designing here?
A: We’re designing the core messaging functionality, which involves communicating in both one-on-one channels and group channels in an organization. You don’t have to worry about channel settings and all of those extra functionalities.
Question 2
Q: Okay. Do you want me to take care of the concept of private channels at all?
A: Let’s just focus on users in a channel as far as access control is concerned; we can forget about the concept of a private channel.
Question 3
Q: Okay. And regarding communication, from my knowledge of Slack, when you load the web app or the desktop / mobile apps, you can obviously access all the messages of channels that you’re in (including one-on-one channels), but you’re also notified of channels that have unread messages for you and of the number of unread mentions that you have in each channel. Channels with unread messages are bold, if I remember correctly, and the number of unread mentions is simply visible next to channel names. Should we design our system to accommodate this?
A: Yes, we should take care of this. And on that note, one thing we’ll want to handle is cross-device synchronization. In other words, if you have both the Slack desktop app and the Slack mobile app open, and both apps are showing that one channel is unread, and you read that channel on one of the apps, the other app should immediately get updated and should mark the channel as read. You’ll have to handle this.
Question 4
Q: Hmm, okay. Speaking of different applications, by the way, are we designing the various device / software apps, or just the backend systems that the frontends / clients communicate with?
A: You’ll only really focus on the backend systems for this question.
Question 5
Q: Okay. Also, there are a lot of different features in actual Slack messages. For example, adding custom emojis, pinning messages, saving messages, writing code snippets or text-blocks, etc… Do you want me to handle all of this?
A: No, you can just treat messages as pure text for now. Of course, what you’ll design will likely be extensible to different types of messages and will eventually be able to handle things like pinning or saving messages, but for this design, don’t worry about that.
Question 6
Q: How many users do we expect to be building this for? And how large is the largest organization on slack? How many users does it have?
A: Slack has about 10 to 20 million users, so let’s go with 20 million. And as for organizations, let’s say that the largest single Slack customer has 50,000 people in the same organization. We can also approximate that the largest channel will be of that same size if all of an organization’s employees are in the same channel (the typical #general channel, for example).
Question 7
Q: Since this is a chat application, I’m assuming that low latency is one of our top priorities, and also, since this service impacts millions of users, I’m assuming that we should design with high availability in mind. Are these correct assumptions?
A: Yes to both of those things, but for the sake of being a little more focused, don’t worry about optimizing for availability. Let’s focus primarily on latency and core functionality.
Question 8
Q: Okay. And are we building this for a global audience, or should we focus on a single region?
A: Let’s handle a single region for this question, but just like with availability, don’t focus too much on this aspect of the design.
Design Airbnb
Many systems design questions are intentionally left very vague and are literally given in the form of Design Foobar. It’s your job to ask clarifying questions to better understand the system that you have to build.
We’ve laid out some of these questions below; their answers should give you some guidance on the problem. Before looking at them, we encourage you to take few minutes to think about what questions you’d ask in a real interview.
Clarifying Questions To Ask
Question 1
Q: Like a lot of other sharing-economy products out there, Airbnb has two sides: a host-facing side and a renter-facing side. Are we designing both of these sides or just one of them?
A: Let’s design both of these sides of the product.
Question 2
Q: Okay. So we’re probably designing the system for hosts to create and maybe delete listings, and the system for renters to browse through properties, book them, and manage their bookings afterwards. Is that correct?
A: Yes for hosts; but let’s actually just focus on browsing through listings and booking them for renters. We can ignore everything that happens after booking on the renter-facing side.
Question 3
Q: Okay, but for booking, is the idea that, when a user is browsing a property for a specific date range, the property gets temporarily reserved for them if they start the booking process?
A: Yes. More specifically, multiple users should be allowed to look at the same property, for the same date range, concurrently without issues. But once a user starts the booking process for a property, it should be reflected that this property is no longer available for the dates in question if another user tries to book it.
Question 4
Q: I see. But so, let’s say two users are looking at the exact same property for an overlapping date range, and one user presses “Book Now”, at which point they have to enter credit card information. Should we immediately lock the property for the other user for some predetermined period of time, like maybe 15 minutes, and if the first person actually goes through with booking the property, then this “lock” becomes permanent?
A: Yes, that makes sense. In real life, there might be slight differences, but for the sake of this design, let’s go with that.
Question 5
Q: Okay. And do we want to design any auxiliary features like being able to contact hosts, authentication and payment services, etc., or are we really just focusing on browsing and reserving?
A: Let’s really just focus on browsing and booking. We can ignore the rest.
Question 6
Q: I see. So, since it sounds like we’re designing a pretty targeted part of the entire Airbnb service, I want to make sure that I know exactly every functionality that we want to support. My understanding is that users can go on the main Airbnb website or app, they can look up properties based on certain criteria, like location, available date range, pricing, property details, etc., and then they can decide to book a location. As for hosts, they can basically just create a listing and delete it like I said earlier. Is that correct?
A: Yes. But actually, for this design, let’s purely filter based on location and available date range as far as listing characteristics are concerned; let’s not worry about other criteria like pricing and property details.
Question 7
Q: What is the scale that we’re designing this for? Specifically, roughly how many listings and renters do we expect to cater to?
A: Let’s only consider Airbnb’s U.S. operations. So let’s say 50 million users and 1 million listings.
Question 8
Q: Regarding systems characteristics like availability and latency, I’m assuming that, even if a renter looks up properties in a densely-populated area like NYC, where there might be a lot of listings, we care about serving these listings fast, accurately, and reliably. Is that correct?
A: Yes, that’s correct. Ideally, we don’t want any downtime for renters browsing listings.