| It doesn't take many resources to show the user a form, validate it, and save to a DB. I bet that's what the previous developers thought. What happens if you need to validate the form data against an external service that's coming and going due to the traffic spike? What if your database is rejecting transactions occasionally? What happens when your backup process locks all the database tables? How do you reject duplicate form submissions from people hammering the submit button? Do you query the database to find previous submissions? What happens when a scriptkiddie decides it'd be fun to DDOS the site? How do you differentiate good traffic from bad traffic? What do you do when the cloud provider runs out of space and you can't scale up any more (https://news.ycombinator.com/item?id=22691926)? You need to think of all of these things and many, many more to run a robust online service that can handle spikes hundreds of times bigger than the usual level. It's really not straightforward or simple. |
When "hundreds of times the usual level" is still only 50 page loads per second, and 10 milliseconds of CPU per page would be extreme overkill for anything written in a reasonable way, it actually is straightforward.