This was our plan: prod load, but not super load, not a lot of work that we'd disrupt with bug shakeout. I don't have a good way to simulate production load on our staging environment right now (some day) and that wouldn't have shaken this one out anyway.
This statement is false and has been since the very first work done on the npm cli. npm has, in every version of it that has ever existed, since before there was even a package registry, installed preferentially from its local cache of packages where possible.
Yeah, you're right. It was a simple oversight that we hadn't been caching 404s already, since we already have infrastructure in place to bust cache on publishes. It would have been our next step if necessary (it wasn't necessary to mitigate this flood).
You optimize for the use patterns you anticipate or see in normal usage, because, well, see famous saying about premature optimization. The use pattern we see most often is people installing from pre-determined lists in package.json, so 404s aren't all that common ordinarily.
Your installed base is quite large indeed! Your testing load was a drop in the bucket of our daily usage, but once you released to VS users we noticed. Should be straightforward to design something that works for this access pattern and load, now we know what you need. Typeahead package name completion would be a neat feature.
