Loading...
Customer could browse all category.
Customer could browse items for each category.
Customer could get recommended items.
Customer could submit payment to buy items.
Low latency
High Availability
Scalability
Eventually consistency for items/recommendations
Strong consistency for payment
Security for payment info
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.
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)
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)
See Diagram
See Diagram
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...
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?