System requirements

Functional:

• Track the existing inventory
• Fulfil a customer order by increasing/decreasing the stock for the ordered items
• Ability to replenish the stock for an out-of-stock item
• Receive alerts when an item is low on stock

Non-Functional:

• Scalability (the system should be able to handle thousands of simultaneous users)
• Low Latency (updates to item stock should be real-time, to avoid issues with customer orders)
• Consistency (stock availability should be accurately reflected for all customers, to avoid having to cancel orders)

Entities

Customer

Item

Order

Capacity estimation

Orders per Day: 20,000 (on average)

Items per Order: 3-5 items (on average)

Items viewed before Ordering: 10-15 items (on average)

Inventory size: currently 100,000 items, and we add 1,000 new items/day

User base: currently 50,000 active users, and we add 500 new users/day

At the current rate, our user will reach 50000+(500*365)=232,500 active users in 1 year, meaning almost 5 times the current number of users. Therefore we can expect all numbers of orders / items to grow rapidly (i.e. by a factor of 10x in the next 3 years).

Orders per second = 20000/(24*60*60) = 0.2 queries per second to the Order API (possibly 2 QPS in the next 3 years)

Items ordered per second = 5*0.2 = 1 write per second to the Items DB (possibly 10 writes per second in the next 3 years)

Items viewed per second = 15*0.2 = ~7 reads per second to the Items DB (possibly 70 reads per second in the next 3 years)

At the current rate, our inventory will reach 100,000+(365*1000)=465,000 in 1 year, meaning almost 5 times the current number of items. And approximately 1,000,000 items in 3 years.

If we assume that 1 item needs approximately 1 KB of data storage (itemID=4 bytes, name=50 bytes, description=250 bytes, supplier address=50 bytes, supplier contact details=50 bytes, stockAmount=4 bytes), then 1 KB * 1,000,000 items = 1 GB database size for the items

API design

We will use REST endpoints to communicate with our system:

GET /inventory/{itemIDs} - used to get the available inventory for some items

Inputs:

• itemIDs: a list of item IDs

JSON Output:

• dictionary of {itemID: stockCount}

Considerations:

• The API should be placed behind an API Gateway to enforce authentication and rate-limiting, as we don't want malevolent users to overwhelm the system by sending a lot of GET requests
• Consider limiting the number of Item IDs that can be supplied in a single request

POST /order - used to fulfil a customer order

Inputs:

• userID
• ordered_items:
  • dictionary of {itemID: count}
• delivery address, price, ...

JSON Output:

• orderID

Considerations:

• Ensure consistency by handling simultaneous user orders for the same item(s), and some items going out of stock

POST /reorder_stock - used to send an order to the supplier for one item

Inputs:

• itemID
• count

JSON Output: None

POST /replenish_stock - used when the delivery from a supplier has arrived and the stock can be increased

Inputs:

• itemID
• count

JSON Output: None

POST /signup_alert

Inputs:

• userID
• itemID

JSON Output: None

In general, use an API Gateway to authenticate all API requests and enforce rate limiting. As users should only be able to make Orders or Sign Up to Alerts only for their own userID, etc.

Note that we are purposely avoiding having a POST /set_inventory API, as we don't want to publicly expose an endpoint that modifies the available stock of an item as this is prone to incorrectly modifying our item stock. Instead, the system should privately modify the stock amounts by fulfilling an order (POST /order or POST /replenish_stock)

Database design

Given that we require strong consistency of the Items database, as well as ACID properties (i.e. Atomicity - an order should either succeed or fail completely) then we will opt for a SQL database solution like PostgresSQL.

User:

• PrimaryKey String UserID
• String UserName
• String Address
• ...

Item:

• PrimaryKey ItemID
• String ItemName
• String ItemDescription
• ForeignKey SupplierID
• Integer StockCount

Supplier:

• PrimaryKey SupplierID
• String SupplierName
• String SupplierAddress
• String SupplierContact
• ...

Orders:

• PrimaryKey OrderID
• ForeignKey UserID
• List[String] ItemIDs
• List[String] itemCounts
• String DeliveryAddress
• String Postcode
• ...

An item has exactly one supplier.

An order can have multiple items. An order belongs to exactly one user, but a user can have multiple orders.

Scaling Strategy

• Partitioning: We can speed up our data access by partitioning the tables by columns with low cardinality and high density. For example, for Items we can partition by SupplierID, and for Orders we can partition by UserID or Postcode
• Sharding
• Replicas: Since we need to ensure Consistency, we will only have 1 Write replica, which should be enough given that we expect an average of 1 write per second. However, we can have multiple read replicas since our application is more read heavy (~7 reads per second)

High-level design

Request flows

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...

Detailed component design

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...

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

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?