We recently built a new site for Safe Haven to replace the previous site on the domain with a modern day CMS that our client can quickly and easily update. The site specialises in news about cryptocurrencies so is constantly updated.
When an article goes viral - traffic goes through the roof. Therefore we needed a hosting infrastructure up to the challenge - and we headed to AWS, and their autoscaling features.
Autoscaling means that when your server gets too busy - or just can't perform for whatever reason (if you stipulate the reasons!) - other servers spin up as identical copies to help share the load. We often opt for a blue/green deployment meaning that once the rush is over, the original server gets shut down and the new one (or "ones" - depending on how many you have running by default) remain. You can set up "in-place deployment" instead, which requires your infrastructure to use more than one server by default.
Before you can set up autoscaling you need to consider things like user added content - because if a server is going to get decommissioned / shut down after a spike, you don't want it to take images that people have uploaded with it. Therefore you need to consider something like a separate S3 bucket for all assets - so images are uploaded to a central pot that never gets deleted.
With regards to how and when the autoscaling kicks in, there are lots of decisions to be made about the best approach. You might choose a "round robin" procedure, where visitors are sent to the extra servers in turn - so one to X, next one to Y, next one back to X, next one to Y again. Or you can choose something like "least connections" where the quietest server gets the incoming traffic. Autoscaling can also bounce a visitor from server to server, without them knowing. Or you can use "sticky sessions" - useful where a site involves a login - so people stay put on the same server.
If your site is getting busy and you'd like a hand with managing the load and avoiding a crisis, do get in touch.