Perhaps to make advice easier, I've played around with things like Firebase and Meteor, did a kubernetes tutorial or two, deployed small toy apps on AWS/GCP, as well as have some familiarity with ReactJS/HTML/CSS (I'm trying to get into gatsby but we'll leave that aside), Docker, and the Django/DRF framework. The issue is I don't really know how to integrate them into a "scalable" or "highly available" web application, or even a methodology for comparing scalability for one approach vs another. I also understand CI/CD pipelines are a part of the typical microservices architecture, but would they even make sense for a solo dev vs trying to get a monolith running? Given "scalable" can mean a lot of different things, I'm entirely fine with more open ended answers about focusing on things that will matter more than sheer connections handled and dynamic content served, so please don't feel limited to answering in as few steps as possible if you think there are other insights about better practices/design patterns that should be mentioned.
So for extra context: I'll have a bit of free time in the next couple months to just sketch out ideas and try things (probably the last time for awhile), but I'm genuinely curious how the real software development practitioners would approach an open ended task like this. Unfortunately they weren't exactly offering a class on how to make scalable web apps (probably because there's thousands of different ways) during my pretty conventional college CS program, ya know?
So use the tools and platforms that you already know, that you can hire for, and that will allow you to try out changes rapidly. Do everything you can to keep things as simple as possible for as long as you can -- the more architectural pieces you add now, the more you will have to change later.
100000 simultaneous visitors are a huge number that implies both progressive growth over a long time, without wasting resources in premature, oversized and overcomplicated infrastructure, and a solid business plan (in fact, an exceptional one) behind that growth, making products and services more important and more sophisticated than generic web application scalability.
On the other hand, two months of experimentation can allow you to learn a lot about highly scalable web application architectures and related technology, but building a real one requires an actual business; the most you can do on your own is reimplementing some benchmark.
I just panic and procrastinate. Some of us never grow out of that.
But that aside, pick one of the mature traditional "batteries included" web frameworks to get started. It's never going to be the ideal architecture, but it's not going to be an awful one either. Really learn how to use it, and keep the code quality high from the start. Too many projects I've worked on have ended up in a deep hole because people decided to try a whole new tech stack in production without actually learning how to use it first. Learning by doing is great and all, but there will always be a pressure to "just ship it" instead of reworking all the beginner mistakes that will eventually come back and bite you down the line.
The goal was to provide a hardened boilerplate app with no distinct featureset but at a minimum have things like ORM, user authentication, migrations, as well as a frontend web UI set up so that it could be used as a head-start for any web app projects in the future.
It's built for fast developer experience, while decoupled enough (a la containers) so that it can easily be taken into a kubernetes cluster for scale. (Still a monolith though.)
The project is private now, but happy share it on request. Also happy to answer any questions.
Then use an auth provider and payment processor. (firebase, PayPal) with dbaas.
All that's left is glue and server less functions. And none of the scaling is something you have to do.
Once you get that then sure, peice by piece you can put it on your own hardware and think it through from there (cdn, db)
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.
I’m still working on my idea but I ran some cost and performance simulations and this setup should work well enough at scale at a low cost that once it’s an issue I’m sure I will have enough money to hire experts to build custom solutions to fill any gaps.
What you're asking depends on the type of load. A t-shirt website load will be on the DB, and the need for ACID operations, but a YouTube site will need tons of CPU for transcoding, but losing a comment or two, or them showing up in the wrong order is no big deal so you could use distributed nosql.
But you're trying to run before you can even crawl.
If you're looking at a more realistic load scenario for the t-shirt sitez in reality your first scaling step would be very different to what you're talking about.
Almost all scaling problems for the kind of t-shirt site you describe above can be handled with a couple of carefully chosen in-memory caches. This can literally be a global variable and it'd work fine. Most frameworks have a built-in memory cache that's better, obviously, and can handle asynchronous access/reset gracefully.
If you want to get really fancy, you can even use redis or memcached. Again, many frameworks have that baked in or easily added with a simple library.
In this case, it would be a cache of the t-shirt data for displaying the product page data, and for serving search results.
So instead of using an orm to get the data from the database, you'd keep that data loaded in memory to access it really cheap and fast, and reset the cache (or part of it) when something actually changes, like you add a new tshirt.
To reduce server load you use a CDN for static assets, you'd also pre-resize images into thumbnails, right size for product page, etc. for search results then serve them separately so your webserver's not dealing with them. Something like S3. By scaling them correctly it reduces your bandwidth use, and makes your page load faster.
You don't do image resizing on demand as it's a CPU intensive task.
The rest of the app can be a perfectly normal web app, or monolith as they're known.
The next step would be talking about scaling UP (making your server beefier) for the T-Shirt app, but for the YouTube app you'd be looking at scaling OUT (adding more severs).
Then a couple more steps down the line and you might be considering k8.
Unless you've had the whole app over-engineered by a software architect who doesn't have any real experience. Then you'd have more microservices than customers.
with that said, doing it is easy, but balancing it with budget becomes also tricky.