Hugged to death.
“If you were using federated Kuberenetes with node auto-scaling and the latest cloud-native AI-enabled service discovery OSS tools for geographically aware traffic distribution your static site wouldn’t have gone down.”
“If you were using federated Kuberenetes with node auto-scaling and the latest cloud-native AI-enabled service discovery OSS tools for geographically aware traffic distribution your static site wouldn’t have gone down.”
It's easy to click a few buttons, install some plugins and themes, and wind up running 100+ sql queries on every page load. The various caching plugins work very well, but it's not necessarily something everyone thinks of turning on in advance of getting a lot of traffic all at once.
Can't say if that's what happened here, but it's super common when personal sites linked here go down.
1. lucassimpson.com/about/
Lambda will scale up in seconds.
Dynamo, however, can be set not to (if you wish to stay within free tier limits). Dynamo DB free tier allows 5 4KB/key reads/second, with a buffer for about 5 minutes worth of "tokens" at this rate.
If poorly designed (e.g. using Dynamo like a relational database) you chew through this with app-side joins very quickly. Even if well designed, looking up related articles, or re-loading records on page transition will eat up DB time
As someone else mentioned, caching is critical for this setup to survive this load, especially if you want to stay in free tier... And CloudFront costs pennies compared to Dynamo and Lambda... Though both can easily be cheaper than $5/month
The website actually is fronted by CloudFront.
It's a static site FFS! Erols and ServInt were serving 3k requests per second on a Pentium in the nineties using Apache and SCSI disks with no acceleration, no http cache, no memcache because that 2KB page fits into OS disk cache!
Just like the article implies, if it requires any tweaking and configuration, most people won't/can't do it.