|
|
|
|
|
|
by newusertoday
1553 days ago
|
|
|
I use golang(no framework just pure golang) and my server can serve upto 1500req/sec as tested using ab(apache benchmark tool) on dual core i3-7130u. For scaling it to 100000 req i can go with more beefier machine and scale it vertically or i can use a load balancer and start sending customer requests to different servers and scale it horizontally, this is only possible because selling t-shirt functionality can be handled independently. Homework problem for you how would you keep track of stock of your t-shirts when scaling horizontally. |
|
|
As for the homework...
naive answer: constantly update every T shirt app instance with a record of the current stock, as every transaction completes, and then make sure the system all agrees before allowing additional transactions. Sort of like a really inefficient internal distributed ledger.
horizontial/vertical scale agnostic answer: split the stock tracking into two separate services. One that is focused on managing transactions/maintains the number of T shirts (presumably a hash table for different types of T-shirts with their quantities), the other being updated every time that inventory table changes. The first service can probably be further decomposed into constituent services but for now we'll keep it simpler as a single big one. At page load time the app instance can send a GET (or equiv) request to the secondary service to get quantities of all the shirts on a given page (using matching item ID/hashes) that is then cached in something like localStorage, with ones in limited supply or out of stock denoted as such by the browser/app on render. On a transaction completion you send an update request to the primary stock service, which then begins its process of updating the table/passing the updated table to service two. This will allow customers to add products to their cart with a much lower chance of finding out some are out of stock at check out, but also (hopefully) keeps the stock tracking footprint lower than something like a constantly polling no-matter-what or monolithic tracking system.
Given the bottlenecks I can already see with the checkout transaction part, I'm actually extra curious how to improve it, so I hope you'll share what the exemplar solution would be!