System requirements

Functional:

• Allows users to track the number of each type item
• Allows users to add a type of item
• Real-Time updates of number of items that were consumed or added
• Alert user when a type of item is running low (below 20)
• Allows users to place an order for a type of item if it is running low
• Allows users to add multiple items at once

Non-Functional:

• Should be reliable, data should not be lost and data should be accurate
• Should be available, system should be available at all times

Capacity estimation

Traffic estimates

• 100,000 different companies using this system
• each company holds 2,000 types of item
• Changes in inventory are made 50 times per minute per company

Bandwidth Estimates

• Assuming a request is about 1KB
• Requests = 100,000 * 50 = 5,000,000 requests per min = 84,000 requests per second = 84MB per second

Storage estimates

• Number of items to be tracked = 2,000 * 100,000 = 200 million items
• Assuming each item has a name (1KB), a count (8 bytes), and the company it belongs to (1KB)
• 400 million KB = 390 GB

API design

add_items(company, array_of_items and their count)

update_item(company, item, change)

place_order(company, array of items and the requested count)

Database design

We will most likely have a company table and an items table, hence there exists a relation between the tables, we can use a SQL database. However, SQL tables are not exactly scalable, we want to use a database that can scale, hence a documentDB like MongoDB would be useful.

High-level design

Client -> backend server -> MongoDB

Request flows

Detailed component design

The most important detail here is how can we give real time updates when there are a huge number of changes per second? Whenever an update_item API is called, what we dont want to do is to make the change in DB and then return the results to the user immediately. this will cause high latencies and overwork the database. What we can do instead is to maintain an in memory storage like a HashMap with (company, item) as the key and (count) as the value. Whenever update_item is called, the HashMap will be updated, after a certain time quantum (2 seconds) it dumps the data into the database and return the updates to the user. This is useful because this in memory HashMap acts like a buffer that will track the changes quickly instead of querying the database every time a change is made (which is a slow process), this actually also allows for better user experience, this is because if the results are being returned too quickly, sometimes the user might be confused by the quick changing numbers.

What happens then if the server crashes before the data is dumped into the database? this is where back up servers are needed. The backup severs will check if data has been dumped into the database, if not, it might be an. indication that the main sever has malfunctioned. then the backup server will dump it instead. This allows for data reliability.

After each time data is dumped into the dtaabase, the server will also check if there are any items with a count below 20, if so the server will send an alert to the user.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

Food can expire, hence it would be useful if this inventory system kept track of items that can expire, if there are expiring foods, the server will send an alert as well