How would I go about scaling up something like the exercise tracker from the backend course? Say I had 10k users all logging atleast 4 exercises a month (and viewing them more often than that). Should I continue to use MongoDB Atlas and pay for a higher tier? Or switch to something like postgresql and host somewhere else? And where should I host the app? What costs would be associated with all this? Thanks!
40k new entries a month in total isn’t much. However, the real “cost” would be the “reads”.
10k users looking at their progress could be possible every day, especially at peak times, such as around new years, when everyone wants to get “fit” with their new years resolution, and thus is very active on the platform. You’d want to focus on that case, as if you can scale to that level, then you should be able to give a good experience to most people, and thus retain them better.
Doing some napkin math, 10k users in 1 day roughly = 416 “users” per hour. However, each user isn’t a single request, or “resource”. Each user could use a multitude of resources across the stack, from your database, your server-side code, to even your actual infrastructure, such as the networking.
There is no rock solid answer here however. There are also a multitude of answers on how you can write and manage your app to scale to this level.
Generally however, you’d do this incrementally and not focus on this sort of scale out of the gate. Instead you’d guess the scale you want to “start at”, and pick a platform and architecture that can help you get there. From there you can see your bottle necks and adapt. Do not build for massive scale and spend a bunch of resources if you’re not sure if your app will see those scales.
You could, this would probably be the first move you make due to the simplicity of just “getting a bigger boat” to handle hits. However, you’d only do this if your database is a bottleneck. At the scales of 10k user’s, you’d probably run into network/CPU bottlenecks. Mongodb (and other databases) can scale “horizontally” where you have actually multiple “shards” or database instances that can all work together to handle your app. This way they can share the load between them and act as multiple “nodes”. This gets more tricky than just having a more powerful CPU processor for a single instance however, and obviously running multiple shards/nodes can get more expensive faster.
This is one area where there is a clear answer. The cloud. The cloud is a generic term slapped onto a lot of things. For you however, this means being able to pay someone for their infrastructure and services to help you scale. The major cloud providers are big tech companies such as AWS (Amazon Web Services), Azure and GCP (Google Cloud Platform). These companies pay billions of dollars to build data centers so you can pay them to get some of those data center resources as you need them. This means you could write your app, deploy it to Amazon’s vast data center network and scale up and down with the click of a button, or automatically.
This allows you to save costs, and scale when needed. Lots of big name companies do this. There are some drawbacks such as what if AWS itself goes down, but the advantages outweigh the risks, especially if you have limited resources yourself.
It depends on what you optimize for. If you optimize for user experience you could make your entire stack extremely optimize for high scale, but then you’d end up paying a lot more. You could also optimize for cost and pick a more limited approach that leverages “cheaper” infrastructure and tech. Something like using an API service such as Firebase (also from Google) would allow you to get going faster, but be “vendor locked” into that platform. Such a platform would give you the basic support you’d need to handle most requirements, and scale as needed. But you’d lose out on a ton of freedom and choices in regards to your actual code.
Furthermore, there is no magic bullet. You can use something like Firebase, write your app poorly and end up spending stupid amounts of money in incredible short time spans. Such are Firebase horror stories where people end up burning through thousands of dollars per hour, so do take care before trying to gather large amounts of users!
Finally it’s worth mentioning that there are a number of factors going into what would be the “best” solution. What works for 1k users might not work best for 10k, or let alone 10 million. There is also the ultimate problem of getting user’s at all, never mind if you can scale into the billions if you can’t get people to use your platform!
Good luck, keep learning, keep building 
1 Like
Thank you for the very in-depth response! Lot’s to think about!
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.