Associate
I think even implementing a solution specifically for the GPU launches and having the buy buttons direct to that may alleviate the issue while allowing your current setup to operate as-is the other 99% of the time.I understand that there are systems built to handle things like that...ticket websites for example. However, these are specialised and our requirements for an ecommerce site are much more complex and varied. We can't build a business on a platform which is built for the few "big launch days" rather than the other 362 days of the year.
We "spun up" a number of extra servers before the launch and more afterwards. However, this probably made the situation worse, because it enabled thousands of people to access the product pages simultaneously and so many concurrent secure connections caused issues with the database. Lesson learned I hope. We'll look into whether we can resolve it in future.
With that said, I don't believe such an implementation would be orthogonal to operating a general e-commerce store; in fact it's typically the general stores that have lower complexity than a highly available, scalable counterpart.
WRT the site that definitely sounds like changes to DB architecture would be necessitated; I'm assuming you have a traditional SQL setup which will present issues even with scaling due to how multiple writer nodes would need to synchronize - this is why message queues are important as you only have "successful" events hitting the DB and the rest can be discarded once stock hits 0 without querying every time.
I'm conscious of not detracting from the topic too hard here but from you mentioning cloud, I have most of my experience with implementing architecture solutions on AWS, so if that's what you use I'm happy to discuss further in DMs on other possible mitigations for the future.