Let's look at system design problem of designing an e-commerce website like Amazon. We will cover use cases, the system design, APIs, database model and close it with some discussion on concurrency. So use cases are creating user profile or updating user profile. We want to list of products available. we want to add products to the cart finally we want to purchase those products from the cart and a side step we may want to track the orders we have placed so far let's look at the design user will talk to an api layer which on depending upon the request will route to different services for create or update user profile it will talk to user manager which stores user details in the database managed by that service.
For getting the list of products, we talk to Listing Manager, which also has its own data. For adding to the cart, we talk to the Cart Manager, which adds the product to the user cart. For buying products, We talk to the cart manager.
The cart manager updates the quantity in the listing manager. We do so because for a product with 10 quantity we don't want to sell it to 1000 users. Once the quantity is updated in the listing manager, the cart manager will call order managers to create the orders. Orders will have user id and the list of product ids.
Once this is done, It will call the payment manager to make the payment. We don't go into the details of the payment manager because it will call external services. For tracking the order, the API layer will call the order manager to get the list of all the orders or to track a particular order.
This is a great problem for high level system design. You get to create a lot of systems in it. and depending upon the interviewer's interest, you can dive into each of these components which is in itself a complete system design problem.
Let's look at the APIs. The first is the UserManager API where a user can be created or updated. The second is ListingManager which has an API for getting all the products. Here we are returning all the products but it can be improved to you it can be improved to return only a subset of product on the basis of users interest, availability etc. We also have an API of reduced quantity which is called by the cart manager when an order is placed.
We next have cart manager. which adds a single product to a user cart. It takes user ID and product ID and a method for checkout where it takes a user ID finds the cart for that particular user and places the order, reduces the quantity make the payment call and finally returns the order ID back.
This is to display the details of order ID in the website. For order manager We have an API to create an order for a particular user ID. In this, it will get the details of the cart from the cart manager. The next is to track all the products for a given user. Here it will take the user ID and return list of order.
The final API in order manager is the track order where it takes user ID and a particular order and returns details for that particular order. For payment manager, we have only one method make payment where it takes the user id and order id and it returns tracking id for the tracking purposes. Now let's look at the database model.
We have three key entities user, product and order. For user we have id, name, email id, phone and other details. For phone and name we have special structures because they can be very complicated in handling.
For product we have ID, name, price, quantity which is called by the cart manager to reduce when an order is placed. This quantity gets increased when new items are added to the warehouse. We haven't gone into that detail in our system diagram but that can come up when designing the listing manager.
For order we have ID, We also want to associate it with the user ID. It has list of products in it and a date on which it was placed. And it has list of tracking details. These details are whether the product has left the warehouse, whether it is out for delivery or whether it is delivered or not. This is used by the tracking APIs.
We can look at the concurrency. What if two users are trying to order same item? Here in listing manager we can take a lock while updating order details so that only one user is able to reduce the quantity. For the other user it will fail in updating the listing manager hence the checkout process will fail. There can be multiple concurrency scenarios.
We don't cover them. but the gist is to take lock at the appropriate place. It can get complicated in identifying which service you need to take the lock on.
To conclude, it's a very broad problem and a great for high level design. Start by listing use cases, create the simple diagram after that, and depending upon discussion with the interviewer, More detailed discussion can happen on subsystems like order manager, listing manager, payments manager, cart manager etc. A lot of discussion can happen on failure scenarios, scaling etc.
That's out of scope for this discussion but we may create future videos on it. Thank you.