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, index on category, warehouse_id)

• id -PK
• name
• description
• category
• sku
• price
• stock
• warehouse_id

Order (can contain multiple inventory, index on status + user_id)

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

OrderInventory (index on order_id)

• id -PK
• order_id -FK
• inventory_id - FK
• count
• price

Warehouse

• id
• location
• address
• name

High-level design

• order service - place order
• inventory service - manage the updates on inventory
• event sourcing service - read the database updates from the message queue and build snapshots, audit trails.

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

Inventory updates

when updating the inventory, concurrent update may occur, we should use transactions to check the quantity and decrement.

BEGIN TRANSACTION;

SELECT Quantity FROM Inventory WHERE InventoryID = 123;

UPDATE Inventory SET Quantity = Quantity - 10 WHERE InventoryID = 123;

COMMIT;

Monitoring/reporting

When a database updates appen, the inventory service push a message to the message queue, the event sourcing service can then build the inventory table snapshots, also other reporting services can consume the message for reporting purposes.

{

inventory_id: 123

quantity: -1

warehouse_id: 23

timestamp: 12321413

order_id: 123123

}

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.