Loading...
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
The inventory management in build for applications like amazon or shopify to manage their users
1) Admin role management add/update/delete users
2) Add new items to the inventory
3) update items in the inventory
4) Set minium Stock alerts when levels falls below the minium threshold
5) Process Incoming orders and update the inventory
6)
List non-functional requirements for the system...
1) System should be highly scalable it should scale as the number of users incrases or more products get added
2) System should be fault tolorent
Estimate the scale of the system you are going to design...
Based on the discussion with the interviewer
No of qps for admin related queries -> 5 -10
No of qps for staff members who are responssible for upadating the inventory 10-20
No of qps of Customers who will be buying products - >100,000 ->1000,0000
Define what APIs are expected from the system...
Post /v1/User -> This api is used to create new user
{
userId: "",
firstName:"",
lastName:""
}
Delete /v1/User -> This api is used to delete a user
{
userId:""
}
For staff memeber
Post /v1/update - To add or delete the products from the inventory
{
[
{
product :"Product Name",
quantity:1,
addOrRemove:"add"
},
{
product :"Product Name2",
quantity:3,
addOrRemove:"remove"
}
]
}
For Customers - This api is used to add or remove the product from the inventory
Post /v1/update
{
[
{
product :"Product Name",
quantity:1,
addOrRemove:"remove"
},
{
product :"Product Name2",
quantity:3,
addOrRemove:"remove"
}
]
}
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
As the system contains tasks like adding new products to the inventory or deleting few products from the inventory so we will use relational database which provides acid capabilities and also different isolation isolation read uncommited, read commited, repetable read and serializable
In the database schema we will have a products table which will store the productId, product Quantity,amount,minQuantityForAlarm
and we will have another table users which will store the user details and also details of admin and staff members.
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Each user makes a request to the API gateway, which incorporates rate limiters and appropriate authentication to prevent unauthorized access and DDoS attacks. For adding or deleting a user, the request is directed to the user service, which interacts with the users database to save the user details. When adding or deleting inventory, the user or staff member calls the inventory service, which then accesses the inventory database to store the data. To prevent simultaneous updates, we will employ locking methods such as pessimistic or optimistic locking. Pessimistic locking is slower because it requires locking rows before updates, whereas optimistic locking checks the product version and only makes changes if the version remains unchanged since the transaction began. For storing object images, we will use an object storage service like S3, allowing images to be fetched from S3 when displayed on the front end. To scale the database, we will shard based on the product name, placing all products within a specific shard according to the range of their initial alphabetic character. To independently scale the inventory and user services, we will utilize Kafka, enabling the inventory service and API servers to scale separately. Additionally, analytics services can leverage client orders to generate insights, and if an order quantity falls below a threshold, an alert will be triggered to the user. We can use third-party services to email users or develop our own email service using SMTP, POP, or IMAP protocols to notify users when product quantities reach the threshold.
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
As the system contains tasks like adding new products to the inventory or deleting few products from the inventory so we will use relational database which provides acid capabilities and also capabilities to handle transactions
Each user makes a request to the API gateway, which incorporates rate limiters and appropriate authentication to prevent unauthorized access and DDoS attacks. For adding or deleting a user, the request is directed to the user service, which interacts with the users database to save the user details. When adding or deleting inventory, the user or staff member calls the inventory service, which then accesses the inventory database to store the data. To prevent simultaneous updates, we will employ locking methods such as pessimistic or optimistic locking. Pessimistic locking is slower because it requires locking rows before updates, whereas optimistic locking checks the product version and only makes changes if the version remains unchanged since the transaction began. For storing object images, we will use an object storage service like S3, allowing images to be fetched from S3 when displayed on the front end. To scale the database, we will shard based on the product name, placing all products within a specific shard according to the range of their initial alphabetic character. To independently scale the inventory and user services, we will utilize Kafka, enabling the inventory service and API servers to scale separately. Additionally, analytics services can leverage client orders to generate insights, and if an order quantity falls below a threshold, an alert will be triggered to the user. We can use third-party services to email users or develop our own email service using SMTP, POP, or IMAP protocols to notify users when product quantities reach the threshold.
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Each user makes a request to the API gateway, which incorporates rate limiters and appropriate authentication to prevent unauthorized access and DDoS attacks. For adding or deleting a user, the request is directed to the user service, which interacts with the users database to save the user details. When adding or deleting inventory, the user or staff member calls the inventory service, which then accesses the inventory database to store the data. To prevent simultaneous updates, we will employ locking methods such as pessimistic or optimistic locking. Pessimistic locking is slower because it requires locking rows before updates, whereas optimistic locking checks the product version and only makes changes if the version remains unchanged since the transaction began. For storing object images, we will use an object storage service like S3, allowing images to be fetched from S3 when displayed on the front end. To scale the database, we will shard based on the product name, placing all products within a specific shard according to the range of their initial alphabetic character. To independently scale the inventory and user services, we will utilize Kafka, enabling the inventory service and API servers to scale separately. Additionally, analytics services can leverage client orders to generate insights, and if an order quantity falls below a threshold, an alert will be triggered to the user. We can use third-party services to email users or develop our own email service using SMTP, POP, or IMAP protocols to notify users when product quantities reach the threshold.
Explain any trade offs you have made and why you made certain tech choices...
1) Using sql database can help us to handle transactions when many updates are made simultaneously
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
1) Use maching learning techniquest to futher improve the recomendation