System requirements

Functional:

1. Add/delete/Update items in the inventory, changes are reflected in real-time
2. Users receive email/sms alerts when items are in low stock (<=50)
3. Users can fulfill can process customer orders, the system needs to integrate with the order service and the inventory are updated after the order fulfillment.

Non-Functional:

1. highly available
2. strict consistency, the inventory data should be consistent across the system to prevent overselling
3. latency can be relaxed a little bit because of our strict requirements on the availability and consistency
4. scalability, the system must be scalable to handle large volume

Capacity estimation

assume 100M DAU, 50% place an order daily, read write ratio is 10:1. Suppose we have 100k items.

TPS

write: 100M / 2 /10^5 = 500 transacptions/s

read: 500 * 10 = 5000

Storage:

API design

Inventory management

1. post v1/inventory/
   1. SKU, name, description, stock
2. put v1/inventory/{id}
3. delete v1/inventory/{id}
4. get v1/inventory/{id}
5. get v1/inventory/
   1. ids, offset, limit

Order management

1. post v1/order
2. put delete get v1/order/{id}

Database design

Inventory (partition on id+warehouse_id)

• id
• name
• description
• sku
• price
• stock
• warehouse_id

Order (can contain multiple inventory)

• id
• user_id (customer, or seller)
• status (created, inProgress, canceled, completed)
• price
• created_at
• last_updated_at

OrderInventory

• id
• order_id
• inventory_id
• count
• price

Warehouse

• id
• location
• address
• name

High-level design

• order service - place order
• inventory service - manage the updates on inventory

Request flows

Customer order

customer requests listing of the items interested via order service, order service retrieves the details from inventory service. If the customer places an order, order service calls inventory service to update the database.

Replenish

The replenish service scans the database hourly, if it sees an item is low in stock, it puts a message on the message queue. The workers pull from the queue and invokes order service to place a replenish order against the supplier.

Detailed component design

Trade offs/Tech choices

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

Failure scenarios/bottlenecks

We can scale the database by partition the inventory table by id+warehouse_id because the inventory is grouped by locations.

Future improvements

We can consider supporting the hold feature where the item is held for a certain time range after being put to the cart.