"By 7:50 AM, traffic hit the limit of the technology, around 100 page views per minute" (Tone note: Technical discussion about the modern era of development th

"By 7:50 AM, traffic hit the limit of the technology, around 100 page views per minute" (Tone note: Technical discussion about the modern era of development that just happens to be prompted by this article, not a criticism of the targeted site. I've written that sort of website myself enough times!) Yeowch. That's barely faster than a page view per second. I have noticed in several sites (generally APIs rather than end-user sites but the same principles hold) I've built lately that as nice as databases can be, there's a lot of places where things are coded to do a query per page view for things that just have no reason to be doing a query per page view. Even a "no sql" database can slow you down a lot vs. an in-process memory structure. I took one site from being able to serve a few hundred per second to tens of thousands per second by simply taking the relevant DB tables and slurping them wholesale into memory. Whenever someone makes a change to the underlying tables, a "several times a week" operation, I simply slurp the entire database tables in again from scratch. Slurping in the entire DB takes ~.25 seconds for all of its tens of thousands of rows on a low-end RDS and a low-end EC2 instance. Precomputing the answers to "all the questions we saw last hour" (as this is a service queried hourly by a lot of machines) takes another half a second or so. During the second this is happening it's fine to serve stale results from the previous version of the memory contents. My point is I see a lot of residual code and frameworks and habits from an era that come from an attitude of 5 megabytes being a lot of stuff, but it really isn't anymore. Obviously you can't do that to thousands of things without some issue, but almost every application has these little tables like a sidebar or the list of types of X or all kinds of other things where you're better off just slurping the table into RAM and slurping the table into RAM again if there are any changes rather than constantly hitting a network database over and over again, because even if it's a completely cached query it's still vastly more load on your systems than a hash table lookup. (There is a bit of trickiness around making sure you detect changes, but one nice thing about "just reload it all from scratch again" is it's feasible. "Update just the changes" always turns into a problem because of the way an error, once made, echos forever, but "just reload it all from scratch" is a feasible level of complexity.) I also blame the "shared-nothing" architecture for hanging on longer than it needed to. It is OK to use the architectural patterns without literally throwing everything away on every web request. I think what I describe above can still just be considered a glorified DB cache if you do it correctly, which is fine to "share". There's a ton of websites like this in the world where every page load makes dozens or hundreds of DB queries that don't change their results more than "several times a day" and as a result are very slow for no good reason. (Many of these websites could also just run the queries every hour and serve the results with little to no loss in most cases. You want your "published stories" to update immediately, but you probably don't need adding a site to the sidebar to be reflected instantly, etc.)