| 1000 concurrent visitors is literally 31 billion page views per year if you assume a whopping 1 sec. 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. |