Swiggy Interview Question
SDE-3sCountry: United States
Item Table: shard by ItemID
Cart Table: shard by UserID
Item Availability: stored in redis (key = ItemID)
When a user clicks on Add to cart, it quickly checks in Redis the availability and moves forward in the checkout flow.
RDBMS can easily handle 3k writes/sec,on a single table, in a single shard.
So, for storing Item & Cart table, RDBMs is good enough for this usecase, but, if it can't scale for this load, we can go for Redis to store this data also.
Let me know if you see any issue with this approach or it looks good.
Is it 20k orders across all the Items?
- Ashok October 27, 2020Two approaches:
a)
RDBMS can easily handle up to 3K writes/sec, with Sharding technique based on ItemID, we can easily handle this load.
Updated availability of each Item is present in DB. Every time someone searches, we can show whether it's available or not, based on a flag that's present in Redis, which is updated only when it goes Out of stock.
When a user tries to add to Cart, if we reserve the Inventory, we end up creating so many Carts in DB. We can't store all Carts in single table/shard. So, even Cart has to be sharded, based on UserID. So, this way, both Inventory & Cart table can scale well.
b)
If Redis is used to store Inventory of all the Flash Sale Items, it can easily handle 20k/2secs of writes. We don't even have to shard it.
If we so much load that a single Redis shard can't handle it, we can shard it based on ItemID.
Cart table can be sharded by UserId.
Item table: sharded by ItemID in RDBMS/Redis.
Cart table: sharded by UserID in RDBMS/Redis.
Item availability: stored in Redis (key = ItemID)
Let me know what problem you see from this approach or it looks good.