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) Allow users to use analytical service to generate dashboards and analyze analytics
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.
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 and address race conditions when multiple users make concurrent modifications, 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. Additionally, to handle out-of-stock scenarios during high demand, the system will implement mechanisms to prevent stock levels from reaching zero or negative by enforcing inventory checks before processing orders.
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 ensure data integrity, especially in cases of errors or failures during inventory updates, the system will incorporate robust rollback capabilities to revert changes as needed. Furthermore, disaster recovery strategies will be established to handle database failures or data corruption, including regular backups, failover mechanisms, and data replication across multiple regions.
To independently scale the inventory and user services, we will utilize Kafka, enabling the inventory service and API servers to scale separately. Kafka will also be leveraged for event sourcing to effectively manage state changes within the system, rather than solely for messaging. 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.
For performance optimizations, frequently accessed inventory data will be cached using Redis or Memcached to reduce database loads and enhance response times. To maintain operational excellence, monitoring tools like Prometheus and Grafana will be integrated to ensure application health and availability metrics are readily available. These tools will provide real-time insights into system performance, enabling proactive identification and resolution of potential issues. By addressing these potential gaps and incorporating advanced performance engineering, event-driven architecture, and comprehensive monitoring, the system will achieve high scalability, reliability, and efficiency.
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...
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 and address race conditions when multiple users make concurrent modifications, 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. Additionally, to handle out-of-stock scenarios during high demand, the system will implement mechanisms to prevent stock levels from reaching zero or negative by enforcing inventory checks before processing orders.
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 ensure data integrity, especially in cases of errors or failures during inventory updates, the system will incorporate robust rollback capabilities to revert changes as needed. Furthermore, disaster recovery strategies will be established to handle database failures or data corruption, including regular backups, failover mechanisms, and data replication across multiple regions.
To independently scale the inventory and user services, we will utilize Kafka, enabling the inventory service and API servers to scale separately. Kafka will also be leveraged for event sourcing to effectively manage state changes within the system, rather than solely for messaging. 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.
For performance optimizations, frequently accessed inventory data will be cached using Redis or Memcached to reduce database loads and enhance response times. To maintain operational excellence, monitoring tools like Prometheus and Grafana will be integrated to ensure application health and availability metrics are readily available. These tools will provide real-time insights into system performance, enabling proactive identification and resolution of potential issues. By addressing these potential gaps and incorporating advanced performance engineering, event-driven architecture, and comprehensive monitoring, the system will achieve high scalability, reliability, and efficiency.
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 and address race conditions when multiple users make concurrent modifications, 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. Additionally, to handle out-of-stock scenarios during high demand, the system will implement mechanisms to prevent stock levels from reaching zero or negative by enforcing inventory checks before processing orders.
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 ensure data integrity, especially in cases of errors or failures during inventory updates, the system will incorporate robust rollback capabilities to revert changes as needed. Furthermore, disaster recovery strategies will be established to handle database failures or data corruption, including regular backups, failover mechanisms, and data replication across multiple regions.
To independently scale the inventory and user services, we will utilize Kafka, enabling the inventory service and API servers to scale separately. Kafka will also be leveraged for event sourcing to effectively manage state changes within the system, rather than solely for messaging. 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.
For performance optimizations, frequently accessed inventory data will be cached using Redis or Memcached to reduce database loads and enhance response times. To maintain operational excellence, monitoring tools like Prometheus and Grafana will be integrated to ensure application health and availability metrics are readily available. These tools will provide real-time insights into system performance, enabling proactive identification and resolution of potential issues. By addressing these potential gaps and incorporating advanced performance engineering, event-driven architecture, and comprehensive monitoring, the system will achieve high scalability, reliability, and efficiency.
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