Loading...
100000 * 20b (search) * 4(number of searches) * 30 (items) = 240 Mb
User data: address (50b) + payments (50-150b) + name (20kb) = 150 Mb
searchProduct(query) {
item {
title: string,
description: string,
cost: string,
headlinePicture: MediaUrl
product_id: UUID,
}
pagination: page, size
}
getProduct(product_id) {
title,
description,
cost,
pictures,
product_id,
}
checkout(
userId,
name,
address,
payment
) {
success: boolean
}
updateCart(
userId,
product_id,
count
) {
success: boolean
}
updateUser(
userId,
name,
address,
payment
) {
success: boolean
}
addProduct(
userId,
title,
description,
cost,
pictures,
product_id
) {
success: boolean
}
User DB: Postgres to with pessimistic locking, shard on hash
Item DB: Postgres, ranked trie with k-top of 30 in the first node. When a user purchases an item the rank of the item will improve. We can use Apache spark to batch process and update the DB
Transaction DB: Postgres to ensure guaranteed transactions and ids
Product Service: will query the Item DB, which will have a ranked trie. Each word in the search term will be a prefix. Will also get individual products
Product Cache: Redis cache using Cache-aside: The application communicates directly with the database or cache to check if the requested data is available. This strategy is useful for read-heavy applications.
Cart Service: keep track of what is in cart. Save incase use leaves the page. The user DB will have a list of items in cart
Checkout Service: Will enable the user to checkout and update the Item DB and add a transaction to the transaction DB.
ELK: will allow us to analyze our checkout logs and ensure there are no issues with users checking out
LB using the least connections
gateway to rate limit malicious users
product service will check the cache to see if something similar has been queried. The cache will live for one hours since there are so many products being added daily. If it's a cache miss then read from the Item DB Read. This will allow the Item DB to focus on writes/new items added. Apache spark will read from the item DB in batches to update the item DB read.
The checkout service will ensure transactions go through with postgres. Implementing retries and switching regions if a particular region is down. The logs from this service will be picked up by Elastic Search, logstash, and kibana to get more insight on how much the platform is selling.
Item DB needs to shard based on something but not sure what. This will be an issue growing horizontally.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?