System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

• Users can search for products
• Users can put products into a cart, cart items will persist even if they leave
• Users can purchase and pay online
• Users can track their order status
• Users can browse personalized recommendations

Non-Functional:

List non-functional requirements for the system...

• The site must be scalable, supporting millions of users
• Page load times should be reasonable, browsing page should have some results within 1-2 seconds
• The site and features should be highly available
• Data must be consistent. Users should not see items missing in their carts, or have issues with their purchase history, etc.

Capacity estimation

Estimate the scale of the system you are going to design...

• Our service must support millions of TPS for loading products, adding to cart, and thousands TPS for purchase
• We will be supporting 100 million products. Also products will have associated images -> PBs of storage required.

API design

Define what APIs are expected from the system...

get product - product_id

purchase - cart_id

search - query term

recommendations - infer user from headers

order status - order_id

update order status - order_id, status

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Since strong consistency is a requirement for orders and products - we will choose an SQL database which offers ACID guarantees. We should stick to one type since we have relationships between users, orders, and products that SQL databases handle well with efficient queries.

Query patterns

• get product - by id
• get order, update order - by id; get order where user_id = 'user'
  • index on user_id
• get cart - get orders by user_id = user and status = 'cart'
  • add a composite index of (user_id, status)

Products - id, description, price, 

Orders - id, cart_id, status

Users - id, name

product counts - product_id, click_count, purchase_count

• has simple read and write access pattern, use a NoSQL key value store for simplicity, 
• partition key - product_id, sort key - purchase count

One concern is working with 100 million products with heavy read requests as users click on products, we will need to shard the products table. Range based sharding is better for a table that will grow (no re-hashing and moving data around nightmare)

Replication will be important for data durability - though since we're sharding already, let's keep it simple and keep all writes and reads to the master node.

Add a Redis cache for Products, it will take read pressure off of the table,

Read from cache first, else get from DB. Use a LRU eviction policy, the most popular products will stay in the cache.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Client

LB

Web servers  

search service, recommendation service, payment service, Auth server

Data Layer

recommendation service -> orders (query by 

• Web servers scaled horizontally behind LB
• For purchasing and adding to cart, we will update the DB with new orders info, cart info
• For search, we will hit our search service with the search query and return a list of products (maybe bad to mention since i don't know the details - we should paginate these results, elasticsearch supports flexible queries with configurable page sizes). Web service will then get products by id from our data layer and return to the user.
• For recommendations, a recommendations service will return a list of products that would interest the specific user. (paginate results)
  • Check a user's purchase history to get purchased products. Call encoder ML model to generate embeddings for each product, and search against our products elasticsearch cluster for relevant products using KNN search.
    • this is too slow, we should also store product embeddings in our DB so that we don't need to compute those in runtime
    • For popular products, we can compute similarity offline and put it in a cache
    • ML model cluster should also be (auto)scaled separately, as we will mostly be running large jobs offline periodically.
• Unsure about payments… use a 3P like Stripe.

Offline

products db <- worker -> index search cluster. 

• Initially we will need to process all products and add them to an Elasticsearch cluster and build an inverse index of product_name, product descriptions -> product_id. 
• Here we will also generate entity embeddings for each product with our ML model
  • features will will use to train - title, description, main image

product recommendations cache <- worker -> product_counts

     -> ML model

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

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...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

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

Future improvements

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