Not criticizing the core idea, which is sound (don't waste ressource overengineering at the beginning, evolve your architecture to match your actual scale as you grow), but the “number of users” figures in this post are completely nonsensical. You ought to multiply them by 100 (if you're being conservative) or even 1000 (depending on the consumption pattern for the user). Modern hardware is fast , if you cannot fit m…
Depending on usage patterns you can go higher.
I put well over a few thousand users on a single $5/m DO droplet. The backend was a single Go binary updating a postgresql DB (on the same machine) as and when users finished their mandated training material, keeping track of which slide they were last on.
The actual training slides were served statically.
Python is slow; I mean, like really slow. Java and C# requires extra RAM, and not just a little - 1GB minimum for any webapp you intend to build.
Jenkins, written in Java IIRC, was not able to run on that $5/m droplet even serving just a couple of users. A Django app I built also had trouble with acceptable response times with just a a few users too.
My little Go binary, OTOH, peaked at 300MB RAM usage and had no problem even with 1000 users all logging in at 0800 and rapidly running through their training.