For database it depends, for redis and memcached you have elasticcache. For SQL databases it will depend on the architecture of your application and your sharding strategy.
True, it always depends, but unless the devs planned for this in their architecture, they'll have a greater bit of difficulty scaling up their data storage and retrieval compared to webservers.
Look at the guy from Vaot, he started the site as an expermient to learn ASP.NET and C#. I don't know how skilled the devs are behind this site, but it wouldn't surprise me if scaling to millions of users was not at the top of their heads when starting out. Hell, even sites like Twitter had immense problems because the initial idea wasn't built to scale, nor should it have been. YAGNI and all that.
They are hosted on AWS, they can upscale and downscale on demand.
For webservers yes, you can turn on more vm's to handle more requests. But I don't think that's an option for their database.
For database it depends, for redis and memcached you have elasticcache. For SQL databases it will depend on the architecture of your application and your sharding strategy.
True, it always depends, but unless the devs planned for this in their architecture, they'll have a greater bit of difficulty scaling up their data storage and retrieval compared to webservers.
Look at the guy from Vaot, he started the site as an expermient to learn ASP.NET and C#. I don't know how skilled the devs are behind this site, but it wouldn't surprise me if scaling to millions of users was not at the top of their heads when starting out. Hell, even sites like Twitter had immense problems because the initial idea wasn't built to scale, nor should it have been. YAGNI and all that.
Oh OK. Cool. Makes it an easy decision then if it's so eaay