Loading...
We will need one million items in inventory. We will have 50000 transactions per day. That corresponds to 5 ^ 10 ^4 / 3.6 * 10^3 = 15 TPS for transactions updating inventory.
One item could be 10 KB on avg, 100 KB peak. One million would correspond to 1*10^6 * 1 *10^-1MB = 100 GB
addItemsToStock(String itemId, int stockCount)
removeItemsFromStock(String itemId, int stockCount)
We need a table for InventoryState that has itemId as primary key.
FanOutQueue
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...
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...
Explain any trade offs you have made and why you made certain tech choices...
For FanOutQueue we could use kafka or SNS with SQS. Kafka would allow us to achieve potentially lower latencies and provide persistence of messages, while SNS and SQS could be fully managed by cloud.
It could happen that we updated InventoryState but didn't send an event to FanOutQueue. We could mitigate that by using database triggers. We could also retry the request to add to the queue.
auto-scaling for inventory service.
Depending on the queue we use we could have the message delivered multiple times, clients (ALertProcessor/SalesChannels) should be able to handle that by making their operation idempotent.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?