System requirements

Functional:

Collect user purchase history

Page Views Tracking

Click Tracking

Like or dislike for each product

Tracking products user click like and dislike

Track search history

Track user wishlist

Compare other users has purchased and like most common products. Recommend their other purchases to each other.

Non-Functional:

Scalability: plenty of data of user activities increasing in each user everyday. Database management should be scalable.

Maintainable: Multiple tables mapping are complex. Data table Sharding and decoupling must be important to data engineers narrow down the scope.

Capacity estimation

1. Year 1:
   • Estimated Users: 1 million
2. Year 3:
   • Users after 2 years of 75% growth per year:
   • Year 2: 1 million * 1.75 = 1.75 million
   • Year 3: 1.75 million * 1.75 = 3.06 million users
3. Year 5:
   • Continuing the growth rate:
   • Year 4: 3.06 million * 1.75 = 5.355 million
   • Year 5: 5.355 million * 1.75 = approximately 9.37 million users

API design

Supporting func:

purchased[] getPurchaseHistory(userId)

void addClickedItem(userId, itemId)

itemId[] getClickedItems(userId)

void addLikeOrDislike(userId, itemId, attitude)

Map>getLikeOrDislikeList(userId)

void addSearchHistory(userId, keyword)

itemId[] getSearchHistory(userId)

void addWishList(userId)

wishlist[] getWishList(userId)

userId[] getTopKUserPurchasedMostCommonItem(userId)

ItemId[] getTopKPurchasedItemsByTopKCommonUsers(userId:[])

RESTful API

// Combine all these API above in this API and ranking the different algorithm's by weight

GET /getRecommendations(userId, topK)

return itemId[]

// add new user activity in log, action is for action type eg: search, clicked, like/dislike, etc, keyword use for search action, attitude for like/dislike

POST /logUserActivity(userId, action, itemId, keyword, attitude)

// get user activity profiles

GET /userActivityProfile(userId)

Database design

Here are tables: the key end with "At" means the timestamp action took

Purchased:

[userId, itemId, purchasedAt]

Attitude:

[userId, itemId, attitude, createdAt]

Clicked:

[userId, itemId, clickedAt]

Search:

[userId, keyword, searchAt]

WishList:

[userId, itemId, wishAt]

Recommendation //list all recommended items for each user

[userId, itemId:[], confidence]

High-level design

1. Client: for external users
2. load balancer: distribute traffic to multiple API servers
3. API Sever Clusters: hosts UserActivityService and RecommendationService
4. UserActivityService: Use to Collect User Activities Data to store in ActivityHistoryDatabase. (POST /logUserActivity)
5. ActivityHistoryDatabase: Store tables Purchased, Attitude, Clicked, Search, WishList which mentioned in Database Design.
6. RecommendationService: Extract User Activities Data from ActivityHistoryDatabase then generate recommendation item list by using logic we mentioned in API Design. (GET /userActivityProfile), store recommendation item lists for each user in RecommendationDatabase as well. Then send back to client as well.
7. RecommendationDatabase: store Recommendation table mentioned in Database Design.

Request flows

*Please check my Sequence diagram!

1. Client sent request to load balancer(purchase, like/dislike,search, etc)
2. load balancer assign to appropriate API server to handle
3. UserActivityService received request for new activity(should listening all the time), write new activity event to ActivityHistoryDatabase. Then send a response back to UserActivityService.
4. Once UserActivityService received response from db, server trigger getUserActivityProfile in RecommendationService to get activity data from ActivityHistoryDatabase
5. Once getUserActivityProfile received response then call getRecommendations for top K recommendation
6. update recommendation list for user in RecommendationDatabase, return top K recommendation list to client as well.

Detailed component design

RecommendationService: Here are some strategies we use: All these return should be stored in data structure temporily.(eg: HashMaps and Graphs)

• Get purchased items feature: Fetch items user purchased before and collects those features by categories and choose top 2*K features under each categories. For example:

itemId, name, category, featuresList

0001,Burberry shirt, men clothes, [Burberry, men shirt]

Then search in ActivityHistoryDatabase for the items which have the most same features products items and return

• Get Other users purchased the similar products, find top 2K products which not included in users. purchased list return
• Get liked products in past one year return
• Get WishList products in past one year
• Get search history products in past one year
• Get disliked products, remove products from liked, wished, searched, purchased, or other users purchased return lists

We use the weight of similar products other user purchased return> Get purchased return > Get wishlist return > get liked return > get search history return. Sort the final recommendation lists by this weight order then return top K.

• • Scalability: We can deploy UserActivityService and RecommendationServices on AWS EC2 in different region and add auto-scaling since it's E-commerce system. (Daily time scale up and night time scale down, it's based on performance we saw in monitoring dashboard)
  • Real-Time Recommendations: Need message queue to handle real-time data streams to update recommendations dynamically as user preferences change.

Trade offs/Tech choices

Message queue: Apache Kafka since we can choose different topic to consumer by partitions.

ActivityHistoryDatabase: It's a write heavy database, read by RecommendationServices(we can use WebSocket connection to client and UserActivityService, if activity is not search we need real time recommendation, if activity is search, we better to trigger recommendationService once an hour, which means RecommendationService won't read ActivityHistoryDatabase frequently if activity is search, (mostly they're search) ) So As a write Heavy Database, we need low latency and high availability but not high requirement on consistence because we don't RecommendationService might not read ActivityHistoryDatabase immediately. Apache Cassandra is a good choice.

RecommendationDatabase: RecommendationService triggered write in read-time if activity is not search. if it's search we don't update RecommendationDatabase immediately. So it's a little read heavy Database. MongoDB can be a good choice.

LoadBalancer: ngnix is good. Since UserActivityService might be stateful service, level 7 ngnix might be required. We also might user ZooKeeper to manage server nodes topology.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

Add WebSocket Connector between UserActivityService and Load balancer to trigger read time update

Add Zookeeper for managing server nodes topology.

Add monitoring and alert system to track user activity distribution