System requirements

Functional:

1. Flash Sale System : Concurrent user can view the product and purchase the products.
2. Fair access : Users who selects the product get chance to purchase the product first.
3. Analysis :

Non-Functional:

1. Highly Available: System should be available all the time without any downtime.
2. Low latency and performance : Concurrent users can access the system with minimum latency.
3. Scalability : System should be highly scale and multiple users can access the system concurrently without any issue.

Capacity estimation

1 ) DAU = 10M

Concurrent Users = 20% off DAU = 02 M

Read QPS = 2 M /24*3600=20

Write QPS = 2

API design

1) List the Product

GET /api/v1/search

return list of the product available for sale

2)Purchase the product

POST /api/v1/purchase

parameters { product_id,user_id,count,price}

return success/failure messages

Database design

1) User table

User_id: UUID(primary key)

name :String

address: String

email_id = String

2)Product table

product_id :UUID (primary_key)

product_name: String

quantity: int

inventory_id:int (foreign key)

3) Inventory table

inventory_id:UUID(primary key)

product_id: int(foreign key)

available_Quantity

Sold_quantity:String

4)order table

order_id:uuid(primary_key)

product_id:int(foreign key)

user_id(foreign_key)

status:String

High-level design

Request flows

1) User search request will be authenticated via API gateway and redirect to search Services.

2) Search service fetches the product from search index and we use elastic search for that and then check the availability of the product by calling availability service.

3)Availability services fetches the product availability and quantity from distributed cache.

4) Distributed cache is populated based on CDC ,if there any change in inventory CDC will be triggered and do the invalidation of cache.

5)User can use order serivce to purchase the item and we can use Kafka for asynchronous purchase experience

Detailed component design

1) As one of the major constraints is how the system is available and scalable in case of concurrent peak load for that purpose we are going to use the search index to fetch the product quickly and based on load we can horizontally scale the search service ,Secondly we need to peak the product availability and quantity we need to call availability service fetched the real time data from distributed cache and we can use Redis for that .We can also have two level cache one is in-memory cache to peek the recent product search and second from Redis .The Redis cache invalidation will be based on CDC pattern and we want to have almost real time consistent data to avoid the excess product sale.

2)To handle the concurrent users and access of inventory and place order in fair manner we can plan to have epoc time stamp when user select any product during flash sale and then use Redis sorted set to sort the order based on epoc timestamp and then allow the order to process in that order for fairness

Trade offs/Tech choices

1. I have chosen the Distributed cache for quantity check it is real time cache but in some case will have access inventory sale if the cache is not invalidated properly as we have multiple concurrent users in multi threaded environment.But as system has to be more scalable i have opted for this solution

Failure scenarios/bottlenecks

1 .

Future improvements

1. I have chosen the relation DB for product table but we can use no sql DB like cassandra for avoid doing schema changes.
2. We can go for shard based approach to maintain the quantity for the flash sale product ,we can use redis counter for the fixed quantity in multiple shard and decrement the counter and eventually update the inventory table to avoid the over sell of the product in current approach