System requirements

Functional:

Customer could browse all category.

Customer could browse items for each category.

Customer could get recommended items.

Customer could submit payment to buy items.

Non-Functional:

Low latency

High Availability

Scalability

Eventually consistency for items/recommendations

Strong consistency for payment

Security for payment info

Capacity estimation

Assume 1B daily active user

Read QPS:

1B / 100k = 10k

Peak Read QPS: 10k * 2 = 20k

Assume 1% user purchase one item

Write QPS:

1B * 1% / 100k = 100

Peak Write QPS: 2 * 100 = 200

Storage estimation:

Assume the system has 100M items. Each item will take 1MB to store item information, photo and videos.

In total the storage need:

100M * 1MB = 100TB.

Each item will need to store 3 replicas. So in total the storage need: 3 * 100TB = 300TB.

API design

GET getAllCategories

GET getItemsForCategory(categoryId)

GET getRecommendationsByUser(userId) (This is to recommendation items for curtain user. The the recommendation items is for the user only)

GET getRecommendationsByItem(itemId) (This is to recommendation items for curtain item. The the recommendation items is for the item. For example, when user put item A into cart, then the system will call this api to get recommendations based on item A)

GET getCartInfo(userId)

POST addItemToCart(userId, cartId, itemId, itemQuantity)

POST submitPayment(userId, cartId, paymentType, paymentInfo)

Database design

SQL DB:

Category Table:

categoryId (primary key)

categoryInfo

Item Table:

itemId (primary key)

categoryId (reference key to Category table)

Cart Table:

cartId (primary key)

itemIds (array of itemId, reference key of item table)

subtotal

tax

total

Order Table:

orderId (primary key)

cartId (reference key to cart table)

status (enum of order status: payment pending, payment complete, payment fail)

Payment Table:

paymentId (primary key)

orderId (reference key to order table)

paymentStatus (enum of payment status: pending, complete, fail)

paymentMethod (enum of payment method: visa, master, paypal)

paymentReferenceId (reference id of the 3rd party payment library, the reference id will be used to query the payment status or refund the payment)

Recommendation NoSQL DB:

RecommendationByUser:

userId (primary key)

itemIds (array of recommended item ids)

(This RecommendationByUser table is to recommendation items for curtain user. The the recommendation items is for the user only)

RecommendationByItemIds:

itemId (primary key)

itemIds (array of recommended item ids)

(This RecommendationByItemIds table is to recommendation items for curtain item. The the recommendation items is for the item. For example, when user put item A into cart, then the system will call this api to get recommendations based on item A)

Blob DB:

Blob DB to store the items media info (images and videos)

High-level design

See Diagram

Request flows

See Diagram

Detailed component design

Trade offs/Tech choices

Failure scenarios/bottlenecks

Our non-functional requirements are scalability, fault tolerance, availability and low latency. Let's discuss how the proposed system fulfills these requirements:

1. Scalability: The proposed system is scalable to handle an increasing number of requests. The required resources, including load balancers, services, DB Cache, SQL DB, NoSQL DB could be horizontally scaling. They will be sharded by itemId and userId. They will be added/removed on demand.
2. Fault tolerance: The DB Cache, SQL DB, NoSQL DB will be sharded by itemId and userId. Each shard will have at lease 3 replicas. The replicas will be located in different data centers in case the whole data center is down. Moreover, the redundant resources are always there to handle the failure of a server or its component. Monitoring service is used to enhance reliability by continuously observing system health, detecting issues early, providing insights for optimization, and assisting in timely incident response.
3. Availability: The system is highly available by providing redundant servers and replicating data on them. When a user gets disconnected due to some fault in the server, the session is recreated via a load balancer with different and redundant database clusters, which provides high availability and durability.
4. Low latency: We can minimize the system's latency. Because we use DB cache as the read replica, the read request could read from cache. Also the recommendations are pre-calculated by ML models and store to a NoSQL DB for fast ready. The recommendations will be eventually consistent in return of low latency.

Future improvements

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